Book review: Clean Code - “A Handbook of Agile Software Craftsmanship”

by Robert C. Martin

To write code that will last for a long time, over iterations and between programmers, focus must lie on writing Clean Code. After stating that, what does Clean Code actually mean and which rules should a programmer follow? These are my thoughts after reading Clean Code by Robert C. Martin. Overall a must-read-book for a developer that is into refining his/hers profession into a true craftsmanship. Another book worth reading in that area is: Software Craftsmanship – the New Imperative, by Pete McBreen.

An overview of the book’s structure

The book is presented in three different sections. All well written, with the focus on presenting a good suggested solution. In the introduction there is a “definition” of what bad and unstructured code is, that I found very funny and true:

“The only valid measurement of Code Quality: WTFs/minute” – Robert C. Martin.

First section is all about the principles, patterns and practices of clean code. A few of the mentioned and useful areas are how to format your code, how to comment, error handling and how to build your functions.

Second section is presenting cases. All the cases are discussed from a clean-code-perspective and how to enhance the code. Many of these code examples are situations that you have been in yourself, at least that is what reflected over. It gave me many things to think about and at least from what I have thought about since reading the book, made me write better code. What is classic for a developer is to think that making shortcuts will make you reach the deadline faster, but that is not the case. So you will also find out after reading the book. Writing clean code is not time-consuming, it’s time-saving!

Third section gives you some really good and well structured examples of how to acknowledge code smells and how to solve them. This book even refers to the book: Refactoring, Improving the design of existing code, by Martin Fowler, which I also recommend you to read. It works perfectly as an encyclopedia for code smells, so it is very good to have in the bookshelf for a rainy day filled with refactoring.

My reflections and lessons learned

I will try to reflect over some of the pieces of information in the book that I could really relate to. These are just a few of the points, so that you have something to dwell into yourself while reading the book.

Discussion about comments

Code commenting is something that I have been discussing with colleagues and friends for quite a while. We have always reasoned that for code to be well structured it has to be well-commented. With emphasize on well-commented. After reading the book I really got to think about how easily comments become misleading and obsolete. Because I have found even with my own comments that they easily become redundant and takes longer to read and understand than the code itself. This because you make some minor changes to the function that completely changes the meaning of the comments.

Having some rules that forces you to comment your code often leads to the situations above. Focus should lie on first and foremost writing code that is so clear it is self-explanatory. So if you don’t understand the code yourself, break it down into smaller single action parts so that the code becomes clear. Then commenting at all might be unnecessary.

How to name and write functions

Related to the section above comes the way you write your code and functions. Functions should do one thing! They should also be named accordingly, so that the name itself clearly explains the purpose of the function. This is normally done with verbs together with the predicates “get”, “set” and “is”. There are many standards for naming your code, I always speaks warmly of being pragmatic. If you are reasonably close to the standards and that you within your team and company find a good way and agreement, follow that. It is better to be comfortable within your team than follow a naming standard that somebody else invented and nobody in your team “understand”.

Exceptions

Finally some thoughts about exceptions. The book gave me some good pointers about this. For example one good tip is to write your try-catch-finally statement as a first step when writing a function. In this way you will set the scope of the function. Other issues discussed is of course whether or not Null should be thrown or not, and if null is acceptable to be sent into a function. Read the book and start discussing!

Summary

I really think this is an excellent book to read. It gives you some really good pointers, good patterns and principles to follow and in some way really helps you, at least it helped me, to become a better programmer and professional.

Reference