Book recommendation: Clean Code (Robert C. Martin)

In this book recommendation, I review the book Clean Code by Robert C. Martin, released in 2008. I offer my 13 page summary of the book as free download, and provide links to further reading material.

Introduction to clean code

In 2008, Robert C. Martin (a.k.a. “Uncle Bob”) released the book Clean code. It was not the first book about the topic – books such as the first editions of the Pragmatic Programmer (1999) or Code Complete (1993) preceded it. In contrast to these books, Clean code emphasizes on the code level details, is targeting more modern versions of object-oriented programming languages (here: Java), and is more dogmatic (as in: “do this, don’t do that”).

Defining clean code is actually rather difficult. Robert describes some of the characteristics of clean code:

• Does one thing well
• Is easy to read and understand (especially for others)
• Is (very) easy to maintain
• Has detailed error handling
• Is minimal (as in: rather precise and short instead of long and verbose)

Early on in the book, Robert explains why applying clean coding principles is a good thing: the goal is to shorten the code reading time. Especially when working in teams, developers spend time on reading existing code, before writing new code (the ratio being ~10:1). Developers need time to understand where to put new code, so that it is well integrated into the existing design, using the existing functionality properly. If you spent the time to write clean and concise code, reading that code will be faster, and your team will save time, overall. The fact that writing clean code is generally a bit slower than writing unclean code does make up for the spent effort. Conversely, continuously writing unclean code would produce technical debt and cause a decline in your team’s productivity, because changing the system becomes harder and harder. When managers add more staff in the attempt to increase productivity again, this makes the situation worse. The new team members don’t understand the architecture (or don’t take the time to understand it), creating code that waters down the architecture even more.

Excerpt

Here are a few highlights of the take-aways I got from the Clean code book:

• Take time to create concise, meaningful names, for variables, constants, functions and classes. Don’t be afraid to refactor names over time – don’t expect to find the “perfect” name during the first coding session.
• Write short functions with limited levels of indentation. Functions should do one thing, at one level of abstraction.
• Reduce comments to a minimum, because they tend to become out of sync. They should only describe the “what” when documenting interfaces or abstract base classes – otherwise, they should describe “why” something was done.
• Set up automatic tooling for code formatting, and keep individual files short (usually less than 500 LOC).

Get my book summary

If you want to learn more, I’m offering you my summary of the book (13 pages) for free. I created the summary when reading the book back in 2016. Creating summaries for good books has proven very beneficial for me: I regularly revisit them (e.g. once every 1-2 years), to refresh my memory, or to check where I have to refresh my skills by practicing.

Further reading

There are several other, interesting resources around the topic of clean code, such as:

• Clean code books for specific programming languages, e.g. Clean Code in Python, Clean Code in JavaScript, or Code that fits in your head (C#)
• Clean code developer (also available in German): a website that breaks down the many tricks of Roberts Clean code book into six “grades”, with the goal to help you get them into muscle memory more easily. They also sell colored bracelets for each grade. Wearing them builds awareness for you and your team regarding which clean coding practices you are currently focusing on.
• General advice that is programming-language-agnostic: the newest editions of Pragmatic Programmer, or Code Complete.

For some of the related books that I’ve read and summarized, I will soon publish my summaries as well, e.g. for Pragmatic Programmer, or the Clean Coder book.

Do you have suggestions or feedback for further reading? Let us know in the comments.

Conclusion

I found Robert’s Clean Code book to be an excellent introduction into the topic of improving your code style. I read the book in 2016, and I still regret that I didn’t read it much earlier. Whenever I gave the book to a colleague (who actually read it), I found that their code readability improved a lot. While my summary is a good start, I highly recommend that you buy and read the original work, and to practice, practice, practice!

While reading, you will find some advice that you don’t agree with. This is fine, and Robert even admits that his views may be different from yours, in the same way as one dojo would teach you a martial arts discipline quite differently to another dojo. With increasing coding experience, you (together with your team) will decide which rules to relax.