A simple Google for the query “Best books for Programmers” or “Best programming books” or any variation of that will yield a lot of results with many respected technology sites in the ranks. The programming world has many varied opinions on programming books, one thing that many sites (hackr.io and geeksforgeeks for example) seem to agree on is that Clean Code by Robert C. Martin is among the most important books in programming.
First published in 2009, you’d be be forgiven for thinking that this book is too old to offer much practical advice in modern programming. However, like fashion, it is clear that some things should always remain in style even as frameworks and languages change.
The book lives up to it’s name and hype pretty well, it describes how to best write code that is ‘clean’. What does clean code mean? My interpretation from the book in my own words is:
Code that reads like a story and that is not confronting to begin understanding and working on it.
I remember reading about this book when I first started my forway into the programming world and thinking it was ‘over my head’. After FINALLY reading it, it was heartening to understand the vast majority of concepts and know-how they could be applied practically to my own work. Without further ado, (and for my own future reference), these are my key takeways from the book.
Chapter 2, Meaningful Names
“If the name of a variable, function, or class etc requires a comment or time to interpret, then it is not named well.”
The name of a function or variable or class or anything really “should tell you why it exists, what it does, and how it is used”. There should not be room for interpretation on this point. It can take time to get to this point in your projects, but the important thing to remember is that names can be easily changed.
Chapter 3, Functions
“Functions should do only one thing, and do it well.”
Too often I have written a function that does what I want it to do. However upon reading what it actually does, the name no longer describes it accruately. The book describes that in scenarios like this, do not be afraid to rename functions and extract certain logic from a larger function into it’s own. This way the functions will be easier to interpret, easier to read and, importantly, easier to test!
Side effects are also a ‘gotcha’ in writing functions. These are things that a function does that is not described in the function name could be easily missed by someone reading the code.
“Code should read like a story, it should be easy to follow with each step or next function, following one after the other.”
I quite liked this tip. It is small but a great one to improve readability. Essentially just ensuring your functions are declared in the same order that they will be called.
Chapter 4, Comments
“Comments are to compensate for our failure to express ourselves in code”
This was something that really only begun to click for me after working with some more senior developers. The gist is, if you are writing comments, rethink the code you are commenting on. This could mean rethinking the naming of variables and functions for example so that it is ‘self describing’ and not needing comments. “Comments decay over time, code should not!”
Chapter 9, Unit tests
NB, yes I know there’s some chapters skipped to get here 😁
“Having dirty tests is equivalent to, if not worse than having no tests at all.”
Over the years I have become a big supporter of unit tests, and making them a requirement for myself when writing code. The book describes a really great scenario whereby it’s good to have tests written, however it they become onerous to maintain and update then they are not clean and should be fixed asap. Once tests become a chore, then the likelihood of them being written at all is very low!
Chapter 14, Successive Refinement
“It’s ok to write horrible code first. Just remember to come back to it. Tests are your friend.”
Whilst this takeaway I’m sure is common sense for many, for me it was a strong reminder to not try and do it perfect right away. It’s fine to get your ideas out, and then refine and refactor as you go to keep the code clean.
Chapter 17, Smells and Heuristics
This was by far my favourite chapter. It expands introduces the idea of “Code Smells”. “Code Smells” are a kind of indicator that code is not clean and therefore you should take care when working on it or modifying it. The book outlines a lot of these indicators under certain categories such as:
Functions
- Too many arguments
- Dead functions (functions that are not called)
Comments
- Obselete comments
- Redundant comments
- Commented-Out code
There are so many of them, and again many are common sense, it is great to still see all of them in one place.
Conclusion
Overall, I enjoyed reading Clean Code and took a lot from it. Ii is heavy Object Oriented Programming Oriented which I was finally able to make sense of after delving into the C# realm, but regardless the lessons can be applied for the most part to any programming language and team.