[Book Review] - Clean Code, by Robert C. Martin
Book review #1
It’s better late than never. That is how I felt when I picked this book up. This book could serve as a great user guide before jumping onto any coding adventures in life. Although some of the knowledge in the book has found its way to me over the years by experience (often not good!), there is so much more to learn and it’s so much more refreshing to learn it in a structured way from a single source.
This book made me look at the process of coding and the code in itself, in a different way. I used to look at the clean code concepts as a recommendation, but now I look at it more as a mandatory approach to achieve best results.
After all what’s Clean Code? Let’s hear it from the horse’s mouth itself. Uncle Bob (the author calls himself by this name throughout the book!) funnily puts it this way in the introduction:
What I liked?
Memes aside, the author makes a solid case for the need of Clean Code in the 1st Chapter. He also goes into what the dangers are of messy- smelly code with statistical and anecdotal data. This really helped me to understand the importance of following this approach and dive head-first into projects with these tools from the beginning rather than doing the laundry work later.
In the same chapter the author has collected the definition of Clean Code from various programming stalwarts. I particularly liked the one from Bjarne Stroustrup, the inventor of C++ (a bit biased here as I like C++). He says “I like my code to be elegant and efficient. The logic should be straightforward to make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations. Clean code does one thing well.”
The book can be logically divided into 3 parts. The first part has chapters describing the principles, patterns, and practices of writing clean code. The second part has case studies of ever-increasing complexity. It follows a clean-up exercise or walk-through over the chapters. The third part is a single chapter containing an extensive list of guidelines for heuristics and smells gathered from the case studies.
I really enjoyed the first and third parts of the book. The chapters in these parts touched upon naming guidelines, functions, best practices for commenting in code, formatting, error handling, and unit tests among others. My favorites of the lot were Chapter 1: Clean Code and Chapter 9: Unit Tests that covered Test Driven Development. I can say that the former installed a “clean code” package in my brain through which I see all code now and the latter upgraded the package with an approach to develop future code.
For those enthusiasts who like to watch the trailer before deciding to watch the movie, I have put down important nuggets from some chapters that I found useful (See the post script). Hopefully this will inspire you to take up this book.
What I did not like?
The second part of the book was hard to follow. Mainly because it delves into case studies and exercises using Java. It’s good to go into this with Java know-how. Since I do not have that background, I couldn’t follow this part of the book smoothly. I felt that it would have been better to keep it language agnostic. But again case studies should be specific and maybe that’s why the author picked up a particular language to go with it.
Conclusion
I would highly recommend this book to all budding and experienced programmers. We all want to become good programmers and this book acts as a handy toolbox to have a pleasant and successful programming journey. After reading this book, I now see coding as an art form, just like painting or writing. Striving for elegant and efficient code.
- Happy Cleaning! Happy Coding! -
PS:
Trailer | Clean Code | feat. Uncle Bob
Clean Code:
Bad code can bring a company down.
Spending time keeping your code clean is not just cost effective; it’s a matter of professional survival.
There’s no way to write code without reading it, so making it easy to read actually makes it easier to write.
Apply the Boy Scouts rule: “Leave the campground cleaner than you found it.”
Meaningful Names:
Use meaningful, intention-revealing, pronounceable, searchable names.
Use names that reflect the system domain, context and the problems that must be solved.
Avoid acronyms, encodings and avoid confusing names.
Functions:
The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.
Functions should do one thing. They should do it well. They should do it only.
Avoid duplication.
Comments:
Clear and expressive code with few comments is far superior to cluttered and complex code with lots of comments. Rather than spend your time writing the comments that explain the mess you’ve made, spend it cleaning that mess.
Types of good comments: legal comments, informative comments, explanations of intent, warning of consequences, TODO, marking as important, documenting public API.
Types of bad comments: redundant comments, misleading comments, mandated comments, changelog comments, a comment instead of putting code into a separate function, commented-out code.
Formatting:
Code formatting is about communication, and communication is the professional developer’s first order of business.
Adequate and uniform is required if you intend to communicate orderliness to your code's readers and to provide readability. Use a formatting tool.
Good files are like newspaper articles, with a heading, the important stuff first, and details later.
Error Handling:
Error handling is important, but if it obscures logic, it’s wrong.
Create informative error messages and pass them along with your exceptions.
Don’t return Null and don’t pass Null.
Unit Tests:
Follow the Three laws of TDD:
First Law You may not write production code until you have written a failing unit test.
Second Law You may not write more of a unit test than is sufficient to fail, and not compiling is failing.
Third Law You may not write more production code than is sufficient to pass the currently failing test.
Keep your test clean. The tests must undergo changes in the same way that the code.
Clean tests follow the F.I.R.S.T rule: Tests should be Fast, Independent of each other, Repeatable, Self-validating, and Timely (i.e. written just before the corresponding code).
The test code is as important as the production code.
Classes:
First look for a way to maintain privacy. Loosening encapsulation should always be a last resort.
Classes should be small! Classes should have one responsibility - one reason to change.
Any modifications in the class have the potential of breaking other code in the class. It must be fully retested.
Cohesion must be high. When cohesion is high, it means that the methods and variables of the class are co-dependent and hang together as a logical whole.