I just completed Robert C. Martin latest book Clean Code "A Handbook of Agile Software Craftsmanship", which was a good read but far from as good as his Agile Principles, Patterns and Practices book which I rank among my favorite programming books. If you haven't read it stop reading this and go read it! No just kidding stay..
Clean Code begins with an interesting chapter where the concept of clean code is defined. The chapter includes about a dozen of quotes from famous programmers who are asked to define what clean code means to them. They were all good but I especially liked Michael Feathers definition (author of working effectively with legacy code):
/.../ Clean code always looks like it was written by someone who cares. /.../
I think this is very true, if you really care about the code you write you won't leave it in a messy state but continue to refactor it until your are satisfied.
So why clean code? Well Martin argues, correctly, that the time spent reading vs writing code is very high, and that we are constantly reading old code in order to write new code. So making it easier to read will make it easier to write.
So how do you write clean code? Well that is what the next chapters cover, for example meaningful names, small functions, formatting, unit tests, etc. There are a lot of code in some of these chapters, and I mean a lot. So it can be pretty tedious at times. Robert tries to show step by step how he improves some existing pieces of real code but I found it hard to really follow exactly what he was doing as the code pages were so long and there was no color highlight to mark changed lines or syntax.
I think Robert should consider doing screencasts on writing clean code or on doing TDD, it is a medium that is better suited to showing how you in small steps evolve and change code. These could then later be included on CDs with his books.
Anyway despite it's problems Clean Code is still a good read. I did learn a few new tricks and will be more strict on keeping my functions shorter :)
