Downloaded 896 times
Uploaded byHendrik Ebel
Clean Code (PDF version)
Slides about Robert C. Martins book "Clean Code: A Handbook of Agile Software Craftsmanship". (PDF version)
Clean Code (PDF version)
- 1. Clean Code Hendrik Ebel 10. Mar. 2009 1
- 2. Topics Motivation Meaningful Names Comments Functions By Robert C. Martin & Co. Objects and Data Structures Object Mentor Inc. Error Handling Unit Tests 2
- 3. What is CleanCode? One Question ... 3
- 4. What is CleanCode? 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! 4
- 5. What is CleanCode? 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! 5
- 6. Motivation The Total Costof Owning a Mess productivity vs. time 6
- 7. Aims of CleanCode producing better code @author writing for readers code has to be kept clean over time „Leave the campground cleaner than you found it.“ 7
- 8.
- 9. Meaningful Names variable, functionor class names should answer all the big questions: why it exists? what it does? how it is used? 9
- 10. Meaningful Names If aname 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. 10
- 11. Comments 11
- 12. Good and BadComments •Public API Comments •Redundant Comments •Legal Comments •Noise Comments •Explanation of Intent •Position Markers •Warning for •Closing Brace Comments Consequences •Commented-Out Code •real TODO Comments •Obsolete Comments •Nonpublic JavaDocs 12
- 13. Comments „Purpose of acomment 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 13
- 14. Functions 14
- 15. Functions The goal isto tell the story of the system. „The first rule of functions is that they should be small.“ Do One Thing! Stepdown Rule 15
- 16. Functions Ideal number ofarguments is zero More than three should‘t be used anyway Flag arguments are ugly. Avoid output arguments Side effects are lies. 16
- 17. Objects and Data Structures 17
- 18. Objects hide data andexpose functions easy to add new objects hard to add new behaviors 18
- 19. Data Structures expose dataand have no meaningful functions easy to add new behaviors hard to add new data structures Choose the approach that is best for the job. 19
- 20.
- 21. Error Handling Write codethat is clean and rebust See error handling as a separate concern Use exceptions rather than return codes Use unchecked exceptions 21
- 22. Error Handling Don‘t returnNULL throwing an exception or a special case object like „Collections.emptyList()“ Don‘t pass NULL InvalidArgumentExceptions or assert better: forbid passing NULL by default 22
- 23. Unit Tests 23
- 24. Unit Tests Test DrivenDevelopment (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. 24
- 25. Unit Tests One Assertor Single Concept per Test F.I.R.S.T. Fast Independent Repeatable (in any environment) Self-Validation Timly 25
- 26. Thanks - AnyQuestions? 26
- 27. Sources Book „CleanCode“ 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 27