Home > Book Reviews > Robert C. Martin: Clean Code

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:

Categories: Book Reviews
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: