Review of Clean Code

Clean Code is another book in the genre of “get programmers to write not awful code” which is a genre that I’m a pretty big fan of. Having read Code Complete 2, Refactoring and Working with Legacy Code I was curious how this would compare.

It starts with going through what the author considers smells of bad code. Many of these smells will be familiar to anyone who’s programmed professionaly for a few years but there were some that were new to me and some I found myself disagreeing with. Even if you know them all though it’s worth reading this part as a refresher. In addition it gives the reasoning behind why the author considers them smells and how to fix them.

The second half of the book is very different. It consists of 3 case studies of step by step guides on how the author refactors. He takes a specific piece of code which works but has issues and fixes them. All 3 case studies were production code, including part of JUnit and a command line argument parser. This was something more books should do since tutorials are normally contrived examples not real code. Even if you’ve spent a lot of time refactoring code it’s worth reading how someone else does it. I especially liked that the author mentions changes he didn’t make and his reasoning behind not doing them. However it was difficult to read on the Kindle, since ideally you want to flip back and forth between the cleaned up version and the original.

The last chapter sums up a lot of the points that the book makes into concise rules. It’s by far the most quotable and I found it ended up being the part I highlighted the most. If you see someone quoting this book it’s probably from this chapter

Most developers should read this book. The format of actually showing how to implement the advice in production code as opposed to toy examples is unusual and helpful. It’s not as comprehensive as Code Complete 2 but on the other hand it’s half as long so most people will actually finish it. Even if you disagree with some of the points such as “only write javadocs for external API” and “use member variables to reduce number of arguments to functions” his arguments are well thought out.