Review: Clean Code

Author: Robert Martin
Publisher: Prentice Hall
Published: 2008

The author is none other than Robert Martin, otherwise known as "Uncle Bob". Robert is well-known in programming circles; he is a long-time software professional working at Object Mentor.

The book starts with a number of chapters that cover various aspects of coding best practices. Discussions include naming practices, keeping functions and classes small, writing good comments, encapsulation and abstraction, code fromatting, and component interactions. Two chapters along the way cover error handling and unit testing, both of which I appreciated seeing, as they are important topics. Generally, it wasn’t anything I don’t already know and practice, but it was still good reading.

The first thirteen chapters cover various topics for writing clean code. The next three chapters contain case studies, which apply the information previously provided. The first set of chapters is more theory, while these later three chapters form the meat of the book.

Chapter 14 contains the first case study: a class for parsing command-line arguments. The main point being made here is that creating clean code can – and often does – take multiple passes, or successive refinements, to achieve. One comment that was made is that it is not enough for the code to "work", it also needs to be "clean". The author makes a particular statement that I like:

To write clean code, you must first write dirty code and then clean it.

My experience in writing code has shown me that this is exactly what happens.

The chapter goes on to show successive revisions of the class, from a first draft leading towards the finished version (which, incidentally, was shown first in the chapter). The author makes use of TDD and refactoring techniques to change the "dirty" code into the "clean" version. The steps are documented, and the reasoning behind each change is well-explained. Refactoring is not the point of this chapter, nor is it TDD; rather, the point is that it is necessary to refine dirty code into clean code. Hence, I suspect, the book’s title.

Chapter 15, containing the second case study, looks at a module from JUnit, a testing framework for Java. As with the previous chapter, a "dirty" code sample is shown, and multiple refactorings are used to make it "clean". Again, the changes here draw from the concepts and practices laid out in the first half of the book. The point is made that refactoring is an iterative process, with one step following another. It is also pointed out that an early refactoring may be negated or reversed by a later one. I can relate, I’ve been through this process before. The end result is code that is more readable and maintainable, which is the driving point behind this book.

The final case study, in chapter 16, is based around the SerialDate component of the JCommon library. Robert starts by explaining that the code is already "clean", and that he will critique it and propose ways to make it cleaner. Does he ever. The discussion goes into the guts of the class, with refactorings left, right, and centre. As with the previous case studies, the rationale for the changes are clearly explained along the way. The starting code, along with the cleaner version, is listed in full in Appendix B.

Chapter 17 is the final chapter in the book. It categorizes and details various code "smells" that indicate code samples are not ideal. Such smells include issues of naming, interaction, organization, and documentation. Possible fixes for each are presented as well. Through this listing, the knowledge and practices listed elsewhere in the book are essentialy distilled into one chapter. I think this chapter will be quite useful as a reference when doing code reviews. This chapter is worth the cost of the book.

There are two appendices. The first is a continuation of the discussion on concurrency in chapter 13. The second contains the full source code from the refactoring exercise in chapter 16.

The code shown in the book is all in Java, but this shouldn’t be a problem for any programmer, especially those used to the C-type languages. In fact, the language used is unimportant in the bigger picture: the practices, patterns, and principles of programming.

The bottom line: this book is well-written, and has good content. It even has a useful listing of code smells and ways to counteract them. However, this book may not be especially useful to someone that is well-seasoned in programming, and has made a practice out of following code standards and conventions. It follows that this book is a good read for a junior developer, one that has been programming for a little while and needs education on the concepts presented within. For that aspect, I do recommend this book.