Vladimir Sarić wrote this on September 21, 2011

Book review: Clean Code

I read Uncle Bob’s Clean Code a while back but didn’t want to write about it until I could see what kind of impact it made on my coding and development thinking in general. Now, a few months and a project later, I am positive that Clean Code is a must-read for every develeper. And I realy do mean every developer.

If you are not a Java developer and skim through the book, you might get intimidated by the code you find. But don’t worry, the code is really not too difficult to understand and the explanations are great. There are, of course some chapters which could use a bit less code and a are bit boring, but think of that as a necessary evil. Being a Ruby developer with hardly any Java experience, I didn’t really enjoy reading all the Java code, but I fully understand why Java was used.

My favorite chapters are the first 5, that is the chapters on: clean code in general, naming, functions, comments and formatting. These might be simple topics, and usually they are ignored. However, it’s amazing how much indentation and vertical spacing make your code more readable, not just for another developer, but also for yourself when extending your code or refactoring.

The thing I also really loved was the inclusion of Test Driven Development and constatation that the tests are first-class citizens of your code and with that they should also be “cleanly coded”. This is best seen in the following sentence from the book:

“If you let the tests rot, then your code will rot too. Keep your tests clean.”

The hardest chapter for me to understand and read was, by far, chapter 11 on systems. But this must be due to my lack of Java and system developement experience.

Last chapter is sort of a recap or actually more a reference containing a list of heuristics and smells gathered through case studies examined in second part of the book. If you don’t have time to read the whole book, which you really should make, you should at least read this chapter. But be aware that, as the authors also point out:

“This knowledge base is of limited value if you don’t do the work of carefully reading through the case studies in the second part of this book.”

All in all, I really enjoyed reading this book and will probably read it a few more times, just as every serious developer should.