1. Clean Code
Hendrik Ebel
10. Mar. 2009
Tuesday, March 10, 2009
2. Topics
Motivation
Meaningful Names
Comments
Functions
By Robert C. Martin & Co.
Objects and Data Structures Object Mentor Inc.
Error Handling
Unit Tests
Tuesday, March 10, 2009
3. What is Clean Code?
One Question ...
Tuesday, March 10, 2009
4. What is Clean Code?
One Question ...
elegant
efficient
simple and direct
readability easy to enhance
like a well-written prose
care
no duplications
was made for the problem
...many answers!
Tuesday, March 10, 2009
5. What is Clean Code?
One Question ...
elegant
efficient
simple and direct
readability easy to enhance
like a well-written prose
care
no duplications
was made for the problem
...many answers!
Tuesday, March 10, 2009
6. Motivation
The Total Cost of Owning a Mess
productivity vs. time
Tuesday, March 10, 2009
7. Aims of Clean Code
producing better code
@author writing for readers
code has to be kept clean over time
„Leave the campground cleaner than
you found it.“
Tuesday, March 10, 2009
9. Meaningful Names
variable, function or class names should
answer all the big questions:
why it exists?
what it does?
how it is used?
Tuesday, March 10, 2009
10. Meaningful Names
If a name requires a comment, then the
name does not reveal its intent
avoid disinformation
don't use type information in names
(example: personList)
Spelling similar concepts similarly is
information. Using inconsistent spellings is
disinformation.
Tuesday, March 10, 2009
12. Good and Bad Comments
• Public API Comments • Redundant Comments
• Legal Comments • Noise Comments
• Explanation of Intent • Position Markers
• Warning for • Closing Brace Comments
• Commented-Out Code
Consequences
• real TODO Comments • Obsolete Comments
• Nonpublic JavaDocs
Tuesday, March 10, 2009
13. Comments
„Purpose of a comment is to explain code
that does not explain itself.“
Comments do not make up for bad code
Don‘t use a comment when you can use a
function or a variable
Comments can contains lies
Tuesday, March 10, 2009
15. Functions
The goal is to tell the story of the
system.
„The first rule of functions is that they
should be small.“
Do One Thing!
Stepdown Rule
Tuesday, March 10, 2009
16. Functions
Ideal number of arguments is zero
More than three should‘t be used
anyway
Flag arguments are ugly.
Avoid output arguments
Side effects are lies.
Tuesday, March 10, 2009
18. Objects
hide data and expose functions
easy to add new objects
hard to add new behaviors
Tuesday, March 10, 2009
19. Data Structures
expose data and have no meaningful
functions
easy to add new behaviors
hard to add new data structures
Choose the approach that is best for the job.
Tuesday, March 10, 2009
21. Error Handling
Write code that is clean and rebust
See error handling as a separate concern
Use exceptions rather than return codes
Use unchecked exceptions
Tuesday, March 10, 2009
22. Error Handling
Don‘t return NULL
throwing an exception or a special
case object like
„Collections.emptyList()“
Don‘t pass NULL
InvalidArgumentExceptions or assert
better: forbid passing NULL by default
Tuesday, March 10, 2009
24. Unit Tests
Test Driven Development (TDD)
test and production code are written
together
tests just a few seconds ahead
Keeping tests clean
Test code is just as important as
production code.
Tuesday, March 10, 2009
25. Unit Tests
One Assert or Single Concept per Test
F.I.R.S.T.
Fast
Independent
Repeatable (in any environment)
Self-Validation
Timly
Tuesday, March 10, 2009
27. Sources
Book
„Clean Code“ by Robert C. Martin
ISBN: 0132350882
Images
http://www.failblog.org
http://www.flickr.com/photos/hugovk/199425487/
http://www.flickr.com/photos/jackpot321/1809424991/
http://www.osnews.com/story/19266/WTFs_m
Tuesday, March 10, 2009