As Martin Fowler once wrote, “any damn fool can write code that a computer can understand, the trick is to write code that humans can understand” [1]. Without this reason, we could still be writing code in assembly, and nobody would really complain. But, since maintenance, which obviously includes code reading, takes up a big chunk of the software development budget, it is not enough for code to work. It must also be clean.

So, what exactly do professional programmers understand “clean code” to mean? Martin conducted a small survey, asking some of the most renowned programmers for their thoughts on the subject. As you might expect, these experts mentioned elegance, efficiency, readability, modifiability, minimality, testability, simplicity, expressiveness, and abstraction. In this book’s introduction, you will find their complete responses, along with Martin’s commentary. Once the stage is set, the book proceeds in three complementary directions, which form the basis of its three constituent parts.

The first part, chapters 2 to 13, covers the principles, patterns, and practices of writing clean code, from the point of view of Martin and six of his colleagues at Object Mentor Inc. Here, the authors deliberately “use the popular paperback model whereby the author is responsible for making himself clear and not the academic model where it is the scholar’s job to dig the meaning out of the paper.” These chapters, therefore, are written with an opinion column style. They are to be read more as informal blogging rants than as the final word on the topic. Written by seven different authors, you might find some general disorder, some lack of depth in many topics, and also many loose ends to be pondered. But, even when you might not agree with everything they say, you will still find many commonsense coding guidelines and some witty aphorisms, which are so dear to many agile zealots.

The second part of the book, chapters 14 to 16, includes three particular case studies that illustrate how even well-written code can always be refactored and cleaned using test-driven development (TDD) [2]. The premise behind TDD is that code should be continually tested and refactored. Its motto is: first, make it work (pass the automated tests); then, make it right. This part of the book is particularly interesting for inexperienced programmers because it presents refactoring as an iterative process that is full of trial and error--far apart from the typical textbook examples, which are usually polished before publishing and provide the false impression of a perfect first draft. In this book, however, extensive code listings are provided as the author performs tiny steps to improve the code (keeping the tests passing between each pair of consecutive steps, of course).

The final chapter of the book contains a list of 66 smells and heuristics that the author compiled by walking through different programs and refactoring them. Each time he changed anything, he asked himself why he had made that change, and then wrote the reason down. This resulted in a list that, even though it could hardly be said to be complete, implies “a value system”--the set of values at the heart of Object Mentor’s “school of thought.” Whether you find these kinds of expressions and analogies fortunate or not, you can always find some food for thought from Martin’s incisiveness and insight.

In short, this book makes common sense explicit in the form of coding guidelines, provides three interesting case studies that illustrate the iterative refactoring process needed to produce really maintainable code, and compiles, in a single chapter, many of the underlying heuristics that guide this process. It should be noted, however, that this book is virtually useless for novice programmers, since it assumes some knowledge of automated testing; refactoring; test-driven development; principles, patterns, and practices (PPP); and design patterns, not to mention the need to be able to appreciate the importance of writing clear and maintainable code, something you do not really understand until you have worked on actual projects (lip service in introductory programming classes is not enough). From my point of view, although this book is far inferior to Martin’s excellent PPP book [3], it could still be beneficial as an instrument to spark interesting discussions within your own development team, polish your differences until you achieve a consensus, and, in agile terms, develop your own “value system.”