No! This isn’t a blog about Code Reviews. It’s actually a book review of Bob Martin’s ‘Clean Code’. However the amount of code to read in the book may seem like a series of code reviews (more on that in a bit).
Each chapter contains a different subject to enhance code quality.
From the simple practices that are often overlooked, for example; naming conventions and formatting styles, through the classic tried and tested; Kent Beck’s 4 Simple Rules of Design (Run all tests, contain no duplication, code to express intent and minimize the number of classes and methods); to some gems that can take years to uncover; such as bad practices for returning null (with the correct idiom) and good practices for testing threaded code.
This reviewer certainly chuckled guiltily when reading some of the examples of code that could be written better (”Oh yeah, I remember doing that once!!”).
I was surprised to see a few reviews on other blog sites and amazon about the fact this was not written solely by Bob but by different authors at Object Mentor. I actually thought this was a good thing as each chapter is a separate concern and the writing styles differ so the reader can be engaged differently from one chapter to the next. Plus, there is a lot of Java and the change in temperament clears ones head after reading all that code.
This book does not follow a specific ‘project’ throughout, like many other books today, but concentrates on real world examples to illustrate the points made. This is not a book one can read quickly if the reader wants to real get involved and practice what this book teaches.
One may presume that my opening paragraph was negative on the amount of code in this book. On the contrary, I found this to be an excellent model to get, mainly inexperienced [Java], programmers to look at more code written by experienced experts and take a look at the internals of classes in popular frameworks such as JUnit and JCommon.
Chapter 17 is a concise description of each of the smells and heuristics used throughout the book and if you think you have your coding practices down to a fine art, read through this - you never know where you can learn a new thing or two. Also, if you are still one of the few out there that are not performing Unit Tests (shame on you) then just the first four pages of chapter 9 (p 121 - 124) should sell it to you, and your manager if required.
Now the not so good! Maybe it’s because we are so much into ‘best’ practices that a few things niggled me.
There are a few contradictions in the book. Not only where the advise to never leave commented out code in your application is ignored, but in some cases (e.g. p66) some Catch blocks with no code contain a comment as to why they are empty, while some are indeed completely empty (no comment) - we believe this is not a good practice and is one of the few cases where a comment is indeed useful in a block of code.
I also found a paragraph of slight Utopia-ism (is that a real word?). It is mentioned that programmers should not just get the code working but successfully refine working code before they move onto the next piece of functionality. Unfortunately I know of no customer who would be willing to pay for someone to sit and refactor code when it is functionally working correctly. This may sound contradictory on a Code Quality site but i think it is the real world. I think a better way of arguing this point is to define what is meant when a piece of functionality is ‘done’. This would include the refinement (and documentation which is usually not evident) - maybe I’m just arguing semantics?
In summary this book is a great resource of areas of good coding practices that each chapter has had many whole books dedicated to. I would like to see this book in Computer Science undergraduate courses as I feel to get these practices in early is only a good thing. For any professional, the information contained here in one book gives huge value to the reader.
Recent Comments