Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin Series)

Before I even read the book, I liked the fact that the title contained the words "software" and "craftsmanship" next to each other! This alone is a good reason for many programmers to keep this book where they can see it - every day. The book is well structured, it is well and thoughtfully written - something you would expect from a book of this kind. I am happy to see a book that - in clear and simple terms - promotes what the great Edsger Dijkstra (considered the Father of the Computing Science by many) had been advocating all his life: elegance, simplicity, and intellectual manageability of software. There have been many articles popping up here and there, addressing various aspects of coding standards and general quality of code. Such articles usually would result in heated discussions, mostly fueled by personal preferences, pride, unwillingness of some people to admit that they hadn't been doing things right always... A book like this was needed..

It's good to see a serious book from a serious author who, for example, finally is not afraid to state: "Use unchecked exceptions. The debate is over". This is music to my ears. Surprisingly, however, the author uses checked exceptions in many of his examples! That seems like a really strange oversight. Any plans to fix that in the 2nd edition, Robert? Also, I think the author only scratches the surface explaining why checked exceptions are "not necessary". What is missing is the explanation why checked exceptions are not safe, in the first place. Most of us know that they result in bad and convoluted code. The bigger problem, however, is that they usually result in incorrect error handling in general. And there is quite a bit of confusion and misunderstanding when it comes to error handling among Java programmers - to this day. So, I am afraid, this particularly important advice from the book will be ignored by many programmers raised on checked exceptions - simply due to the lack of clear explanation and the confusing code examples that use checked exceptions.

While I think it is a very good book, I generally agree with one of the earlier reviewers that some topics are covered without the depth necessary to fully illustrate the practice or issue in question.

As one would reasonably expect, some recommendations may have to be taken with a grain of salt. For example, should we really never use HTML in javadocs? Most of us use IDEs that have excellent support for javadoc viewing via key-shortcuts - by simply pointing to the class or method's name anywhere in the code. I never pull up the method's source to read the in-line Javadoc for it as is. I place the cursor on the method name right where the method is referenced, and do Ctrl-Q in IntelliJ. The nicely formatted Javadoc appears in a pop-up window, so I actually like taking full advantage of any HTML formatting. Eclipse or NetBeans users use similar ways. So, I'd say, use common sense, and make sure the comments are informative, and neat. Which is pretty much what the book says anyway.

By the way, speaking of comments, most code examples in the book contain none of those at all! How come? Another strange oversight... I certainly understand that the author assumes that there is no need for javadocs and comments in the sample code since he explains everything in the text of the chapter. However, consistency is another important rule that the author advocates, and I would prefer to see the sample code follow all the same rules the author is promoting in his book.

One of my favorite parts of the book is Chapter 17 - "Smells and Heuristics". This is a great reference guide for any beginner or anyone who only now starts to show interest in writing quality code. Fortunately, most common IDEs today can be configured to inspect your code and look for each of the anomalies listed in that chapter. Turn those inspections on and never ignore them!

The bottom line is that Software Engineering is a CRAFT, indeed. At the end of the day, a programmer should be able to look at his/her work and be proud of it. Those who don't care should probably find a different occupation. For everyone else, this book is a must-read.

(Disclaimer: This review is based on the electronic copy of the book; the hard copy is still on its way from amazon.com at the time of this writing.)

Robert C. Martin is one of the most experienced developers in the world and tries to share his wisdom with the reader, and he does so in a very clear and well articulated way. He says clearly that the book is not THE answer, but rather a summary of his own opinions.

The book focuses on making easily maintainable code.

Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin Series)

First Impressions

I began reading this book with a couple of concerns. First, all the code examples were written in Java, and I haven't written much Java in the last couple of years. Secondly, the books seventeen chapters were written by seven different authors. In my experience, most books with this many authors are at best a collection of uneven chapters, or even worse a morass of redundancy and contradictions. In the end, neither of these concerns proved to be a problem. Instead they demonstrated the authors' point - that clean code is readable code.

The book's main premise is that clean code results from paying attention to the small details (details that are often overlooked in an effort to meet a deadline, or simply get the code working). This overriding theme allows for a seamless blending of each author's contribution into a cohesive readable whole. Where contradictions did occur, the authors not only acknowledged them, but successfully argued that they resulted not from conflicting ideas or approaches, but from differences in priority. Even the high quality of the editing, and typesetting silently reinforce this attention to detail and professionalism. Most computer books have several technical, typographical and grammatical errors in every chapter. I found only a single one in this book (several hundred pages in). This attention to detail silent reinforces the lessons presented in this book.

What's Inside

The book is divided into three parts. Part I (chapters 1-13) demonstrate what makes up clean code, what it looks like, and how to begin creating it (by picking better names, properly using comments, properly structuring your code etc.). By organizing this section into a series of small chapters the reader is able to begin applying these lessons from day one.

Part II (chapters 14-16) contains a series of case studies demonstrating how to apply the rules and guidelines from part I. These case studies show that like refactoring, cleaning code is an iterative process. One that should be undertaken at every opportunity, because all code no matter how good can be improved.

Part III (chapter 17) is a knowledge base. This section documents the rationale behind every change made to the code in the case studies. This final chapter shows that clean code requires both the ability to make the changes, and to know why they were needed.

Final Impression

No book alone can make you a better programmer, anymore than a screwdriver can make you a better carpenter. However, if you have the discipline to go beyond simply getting your code to work, and begin writing clean code, then this book can help you to become a better more professional programmer. If correctly applied over time, it can even serve as a bulwark against an increasingly fragile code base comprised of hacks, kludges and quick fixes. This book not only taught me how to improve my code, but demonstrated that its principals are both timeless, and language agnostic. I would recommend this book to anyone who writes code.


Clean Code A Handbook of Agile Software Craftsmanship
By Robert C. Martin
Published by: Prentice Hall
isbn: 0-13-235088-2

The book contains much useful advice for professional programmers. A bunch of software authors have contributed the book's chapters.

There is one place where I disagree. Where it talks about having commented out code in your source code file. Yes, this often leads to obsolete code, even as commented out code, precisely because as you change various things like variables in the active code, this has no effect on the commented out portions. The book recommends that you simply delete the latter, since you can always retrieve it later via your version control system, which you should certainly be using anyway.

But the book's reasoning is flawed. Simply having the commented out code stored in the version control system is of little use. Out of sight, out of mind. How many programmers are actually going to troll thru previous versions of the file looking for that particular code? For one thing, they have to somehow know or suspect that it might exist. If the programmer currently working on the file is not the author of the commented out code, then there is little likelihood that she will even be aware of this. But even if she was the author of the original code, what if she forgets?

The book's recommendation is an idealisation. The pragmatic reality is that you should, sparingly, keep commented out code in your source files, precisely because it is there in front of you, retaining mindshare, whenever you edit the file. I say sparingly, because you should only do this for crucial code blocks. How to determine this? Well, that is part of your expert knowledge.

I am a front end web developer with a couple years experience and I purchased this book to get a better idea of how to generate more readable and understandable code. And this book satisfied that need. If you are a very novice coder, that is to say that you do not yet know your syntax and are unfamiliar with OOP, you will want to wait to pick up this book. Not that all of the examples and discussion are super technical, just that are many assumptions and no explanations of these subjects.

One of the nice things about this book is its tone - it stays reasonably lighthearted, with a number of naive illustrations to maintain this feel. Nonetheless, it is abundantly clear that the author is fully versed and a master of code, ensuring that all the discussion is well considered and presented.

I do find that the author seems to go a little far in defining his ideal, tho perhaps that is the purpose of an ideal - to guide one's daily path and provide some information as you build out your projects.