Book Review: Clean Code

Why clean code

In the initial chapter of Clean Code¹ Bob Martin makes an unapologetic argument for writing clean code. He knows he has to. The objective of the entire book is to convince you to write clean code. And to do that he has to first convince you that he can define clean code as more than just his opinion.

He starts out pointing out that programming is one part science, and one part art. The science is the knowledge that can come from study and education. Algorithms, Data Structures, and other computer science concepts, of course, all fall under this umbrella.

The idea that writing code can be an art is not original to Martin. The problem is that many programmers believe that art is purely subjective. To these programmers, the idea of “clean” code is merely that of one programmer asserting his aesthetic preferences over others.

Martin makes the point, however, that the arts are not purely subjective. “Being able to distinguish good art from bad does not mean we know how to paint”. Or as my friend Nathan told me: “If art was purely subjective we’d see just as many people listen to the hum of their vacuum, as we do those who turn on a symphony”. The key is that all art requires skill. Where skill is required, there must be an objective (though not necessarily easy) way of measuring that skill.

Programming is a communications discipline

So, then what is the chief skill in software development? It’s communication. Martin says: “code is really the language in which we ultimately express the requirements” of our software systems. When we write code we are attempting to detail exactly what we want our computer to do. This, then, reveals one member of our audience: the compiler, interpreter and ultimately the machine that runs our code.

However it is not for the benefit of the machine that Martin argues we should write cleanly. Clean or not, the computer will dutifully run whatever is written. No it is for the second, and more important member of our audience that we ought to write clean code: Other Developers (including our future selves).

Understanding your Domain

Throughout the book you will see the communication theme persist. But underneath it all there is another theme running. It is the importance of getting an understanding. The objective of any author (literary or programmatic) is to bring readers to an understanding. To get to a “meeting of the minds”.

Sometimes, however, we ourselves don’t understand what we are modeling very well. We know the requirements. We have the set of inputs and we know the desired outputs, but we don’t truly understand the process that we must take to get those outputs from the inputs. That is ok. Just like any author must write rough drafts, Martin frequently extols the value of successive refinement. A purpose of refactoring is to get a working system into one that works and clearly communicates how it works.

Recommendation

This is the primary thesis of the book. Chapters 2 through 13 discuss rules and heuristics for writing clean, communicative code that Martin has acquired over his career coding. In chapters 14 through 16, Martin walks through three different practical examples, showing how he applies his rules to real projects. Finally he closes his book off with a single chapter with a compiled list of rules for writing clean code.

Overall, I highly recommend this book to all but the most novice of programmers. The examples in the book do require familiarity with basic programming concepts, and a reader would benefit with a familiarity with an Object Oriented Language. All the examples are written in Java, but don’t rely on any Java specific features as far as I can tell.

While I don’t agree with every rule that is presented in the book, overall my disagreements are so minor and disputatious that I decided to omit them.

There is one final thought I would like to leave. Socrates was once asked, “Can virtue be taught?”. I want to pose an answer to similar, albeit much less grand, question. Can art be taught?

Martin is hopeful. He spends a good chunk of the book teaching rules, and another large chunk trying to walk the reader through real world application of the rules.

I’m less optimistic. The value of the book is not in reading the rules, but in learning and applying them. When you apply those rules, you will inevitably make mistakes. But that is the only way that you will gain that experience to truly understand them. So while I highly recommend the book, it is in the mind that this is ultimately a practical book. If you read the book, and do not change the way you code, it will be of no value to you.

• Book Review
• Coding