I think either code reviews or static analysis is where the next evolution of testing processes is going to happen. The main problem facing code reviews is that they typically require at least one senior programmer who has seen a lot of code. This is largely because our schools focus on producing people who are more concerned about whether the code works at time of grading rather than on how nice the actual code is. Lets not even think about the long-term maintainability of it. And of course there are those of us who learned by hacking things together as teenagers; we’re a hopeless bunch. Robert C. Martin’s (Uncle Bob) Clean Code could very well be a large part of the solution.

Here’s a quote from the end of chapter 1 which summarizes things nicely: Books on art don’t promise to make you an artist. All they can do is give you some tools, techniques, and thought processes that other artists have used. Uncle Bob and a number of his friends start right at the beginning, Meaningful Names, and start building from there through Functions, Comments, Objects, etc. Each subject gets its own chapter which is then packed with lots of tidbit on the subject with subtopics getting slightly over a page on average. In my copy it is rare that one of these subtopics does not have at least one thing underlined.

One of the strongest parts of the the book are chapters 14 – 16 which are almost like peering over his shoulder as he refactors code. It is one thing to just read a couple paragraphs on something, but another completely to see it put in practice. The next chapter potentially tops those ones by providing a nice list of Smells and Heuristics that you could take with your into a code review or to build a coding standard for your organization.

Perhaps it is my paranoid, Hobbes-ian bent, but I fear this book might also cause just as much damage as it prevents. Too many people I fear will take what is presented as gospel since the authors are well known in the programming world and if they say it then it must be true (in all situations). Having seen a number of codebases, applying all the heuristics that are shown without the appropriate refactoring would result in a collection of source files that are anything but clean and easy to read.

  • Comments are always failures (page 54) – Well, let’s just remove all the comments and / or stop creating them. Too often the code I encounter would be made clearer with a generous helping of comments; or a major refactoring to make them unnecessary. But please don’t do one without the other.
  • Small! (page 34) – In the discussion around function length he retells a program written by Kent Beck where every function was just two, or three, or four lines long. … That’s how short your functions should be. Yes, it is the context of a specific example program, but how many people are going to see that and refactor their nine line function into three three line ones? Later in

Steps were taken to say that everything shown needs to be taken in the context the reader is operating in, including undoing a refactor since it made the code less fluid. I’m not sure it was expressed explicitly enough or often enough.

My only other complaint, and it is a minor one, is the inclusion of sixty pages of source code in the appendix. This sort of thing would be ideal to host online on the book’s website. That alone might have been able to reduce the code of the book a couple dollars and reduced the paper required.

Overall, I think this is a great book which would be at home in a university level course and in the real world either creating or evaluating code. This one is definitely going onto my desk at work. You can get your team’s copy of Clean Code: A Handbook of Agile Software Craftsmanship from this link. Just remember not to forget your brain when applying the techniques to your code.