Robert C. Martin: Clean Code
Clean Code: A Handbook of Agile Software Craftsmanship
- Paperback: 464 pages
- Publisher: Prentice Hall; 1 edition (August 11, 2008)
- Language: English
- ISBN-10: 0132350882
- ISBN-13: 978-0132350884
Personal Summary:
The book can be roughly divided into three major sections with an additional “Prologue”.
In the Prologue the Author and several guest authors explain their personal definition of ”Clean Code” and why dedication to write the best code you possibly can is so important for the individual software developer.
The first section (Chapter 2 -13) describes a set of best practices for writing readable and elegant code. The topics covered range from basics such as variable naming and formatting to recommendations for structuring classes and systems. The reasoning given for each of the recommendations is detailed and comprehensible.
In the second section Martin dissects three code samples and walks the reader through his series of refactorings as he tries to transform the code into a cleaner state. While valuable, the format makes it difficult to follow the changes being made.
The third section contains a set of ”code smells”, similar to those in Martin Fowlers seminal work “Refactoring“.
Opinion and Conclusion:
All guidelines presented are reasonable and well-defined. I got the most value out of the book by reading the first and the third section, while I found the section with the sample refactorings very tedious and not all too helpful. However, comparing the code before and after the refactoring helped to gain an insight into what kind of improvements can be achieved.
Some of the guidelines are no-brainers and are probably the absolute minimum every passionate software developer should stick to.
However, some of the guidelines left me unconvinced. ”A function should only know how do to one thing”. I’m perfectly fine with that guideline and agree with it, but if you take it to the extreme it will make you create three helper methods that are only called from one place. Even worse, you will need to pass intermediate state around (bloating signatures) or introduce artificial state in form of class fields. Not to mention the tight temporal coupling helper methods and the artificial class variables will have. Some of the examples in the book suffer from that “over-abstraction”, I think beyond a certain point readability is actually hurt rather than improved.
On the other hand, the level of abstraction should be high enough so the code is self describing in terms of what it does and should not require additional comments. That’s one of the points that particularly struck me as I read the book: Comments are excuses for bad code, so you should always try to make them superfluous.
In general I could learn a lot from the book and would recommend it for reading. Even if not all the guidelines were 100% convincing, the book helped me learn a critical look at code.
Links and Accompanying Books:
- http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
- I’m currently reading http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052/ref=pd_sim_b_1 from the same series (thanks InishTech!). I think it’s a very good addition. Maybe it’s even more valuable.
. Each of those books has been a valuable support to the work I’ve done lately, so I will continue to expand my library in this and that direction, if I see the above criteria met. This leaves me realizing, how important continuous learning and expanding one’s horizon is, which is fun because the horizon is so huge and there’s always something new to discover. Kind of opposite to what I need to do for school at the moment (fixed horizons, fixed expectations and known solutions)…
