Clean Code – A book to read with a grain of salt
Hey nerds 🤓 ! I am not sure what got you here (except for my god-level SEO skills 😎) or why did you ask Google for this book so that you’re here, but I damn sure know why – of all tech books – I am reviewing this one ! So here’s the story:
Why I bothered reading Clean Code
One day I was at my desk writing code peacefully when my team/tech lead asked me to check Clean Code. This is a team I joined after being off of writing professional code for more than a year “because of covid19” (and my cognitive impairment😆, and the economy, and global warming). I was happy to be thrown into a codebase written in a language I have almost never seen before. From one side I was so confident I can:
- “figure it out” super fast / “find a way” to get the task done✔️ fast
- understand the project and system’s structure and design and get crystal clear on them fast
- stand my ground still on all the fundamentals of mobile development as that’s my speciality for the last 3+ years.
On the other side, I was so terrified of / annoyed by the thoughts of going through the code base, reviewing PRs, or even writing my own code at times. Simply because:
-
I had to try not to make a fist ✊ whenever I see the extract variable refactoring style all over the place. Like how dare they (my peaceful teammates) not put themselves in the shoes of a compiler or of a memory block. Cant we just read a “readable – as per what I saw” instruction by ourselves without cutting it into 700 lines (vars).
-
My autopilot mode just chose namings that match the last programming language I heavily used before switching to this language. Take a look at this masterpiece here where I was (clearly) proud to keep my Java hat on.
-
I had a first week or two to learn my new language’s syntax. I remember the moment I made the revelation that _nobody _is _starting _var _names _with _dashes , it’s just how we say “this a private field in dart”.
Bored of this long intro ? You definitely have the freedom of skipping to the next (main) part.
And hence, my teammate suggesting me Clean Code By Robert C Martin as it was already available in our team’s learning resources set. I picked the book and read a bit of the first chapters which left me with a ” naaaah not for me ” feeling. I used it to lift my laptop stand a bit up though .. 😄
But, a few weeks later I decided to declutter my bookshelf, read the unread books, sell the older than Venus ones, and return this one to my office’s shelve. And so I ” kind-of forced ” myself to read it, and guess what ? I was surprised it has some Good advice !
The thing about Clean Code is that it’s kind-of binary, it has either really terrible advice, or really great advice! It does have good advice especially if you are a novice. But it has so many WTF moments as well. Let’s dive into the details, and you’ll get what I mean.
Our review will be structured as follows:
Book Structure and Contents
This book has 17 chapters that I would group as follows :
A- a bunch of chapters to talk about code and only code:
naming conventions, best naming practices (best according to the author 😅), functions (you know it’s an old book when a chapter is called Functions), “functions” arguments and abstraction levels, comments, formatting(yea, this means it’s a really.really.really old book), and similar topics.
B- a second bunch of chapters to talk about error handling and testing:
using return codes or exceptions, exception handling, third party code boundaries, unit tests, clean tests, TDD, and similar topics.
C- a third group presenting systems, design, and bigger scopes of code:
there’s a chapter here named Classes and another named Objects and Data Structures (yea 🤯) and they are on data abstraction, the single responsibility principle in classes, encapsulation (as if its an OOP book 🤦♀️) and other similar topics. There’s another part on systems, architecture, and scaling up (a very brief and shallow one! I try my best not to review in the section as it’s for “Contents” but its a bit hard 🤐 ), emergent design in code, and similar topics.
D- and a third bunch of chapters about refactoring and refining code:
you can find here better advice than in many other parts of the book, mostly on refactoring and some heuristics for cleaning code. There’s as well much redundancy in these three chapters, but they are still a lot more relevant to the book’s name than any other part.
What I think is Great about Clean Code
1- Awareness is a big first step
Whether you find the advice in Clean Code old, rusty, and irrelevant, or you find it insightful and still matches our today coding world even after 14 years of its release, you will walk away with this: being more mindful about the code you write. It’s a fresh reminder for anyone who comes across this book, that being less random and a bit more intentional about our coding styles, the way we name variables, the way our code uses resources, when to refactor and when duplicate code is needed/fine, when to write tests, how to handle errors, ect .. is always a very good idea ! And such very good idea “kinda” sticks to you after you check this book.
2 – Despite all the “awkward moments” in Clean Code, there’s a big bit of good points !
I will throw here some of the pieces of advice found in the book related to:
- Functions
Functions should not mix levels of abstraction, they should not perform both high-level and low-level tasks, because this is confusing and muddles the function’s responsibility. Function names should be descriptive and should be verb phrases, and have to be chosen carefully. Functions should have no side effects so that we avoid temporal couplings and order dependencies.
- Comments
Use comments to describe the Why and not the What of something. Never comments dead code just delete it.
- Error handling
Throw errors and exceptions rather than returning error codes. Wrapping third-party APIs in a thin layer of abstraction makes it easier to mock the library during testing.
- Others
Software systems are not like a building that must be designed up front. They are more like cities that grow and expand over time, adapting to current needs. Don’t over-complicate your system. Use the simplest thing that works. It’s easier to clean up a mess right after you make it than it is to clean it up later.
What I think is terrible about Clean Code
1- some (a lot of) trivial obvious talks
Take a look at this part of the second chapter with me (or at the the whole second chapter actually!)
from this screenshot, we can see that :
✅ adding the unit of measurement to the name is a good and a relevant advice.
🛑 explaining what a name of a variable should do and giving int d; as an example is a bit trivial! no, like VERY trivial and doesn’t need a book! unless this is a code from scratch course, this shouldn’t be here, in my opinion! it has nothing to do with clean code, it’s more about coding ABCs …
or this one :
like really bro ?!! pronounceable names and genymdhms; as an example ?! 🤦♀️
The book is jammed with similar very trivial, very obvious, very weird tips / talks.
2- A lot of the topics, tips and ideas are literally outdated
It’s not that it’s too bad to look through outdated topics, sometimes we can walk out with a thing or two from outdated information. The least of which is the comparaison between how things were done before and how are they done today and the reflection on reasons and drives for such changes. However, not all outdated information is worth a check ! Especially not a full chapter on formatting code and indentation, when the most trivial IDE today includes a customisable feature to automatically format thousands of lines of code.
3- Okay, let’s be honest, there’s a lot of bad advice hanging all around the book
-
First, the code samples in Clean Code ! Sometimes, they are so weird, so irrelevant and even so much the opposite of what the author writes in his chapters. I don’t know what went wrong here, but how can the writer say something and implement its opposite as sample code. For example, in chapter two we all agreed that methods should have verb or verb phrase names, and yet, we see this function call later on in the book:
wayTooCold()! There is PLENTY of such contradictions in the book, and it’s a bit odd. - Another example is taking the ” methods should not be long ” to the extreme. According to the author an ideal function should have 0 arguments 🤦♀️ (there’s a huge difference between 0 arguments and not much arguments), and that blocks have to be one line long – like a single method call in each block – if we look at the sample code from the book where the author refactored some open source code:
This “refactoring” added to the old code 2 new private constructors and 15 new private methods .. I couldn’t help but be left puzzled and trying to convince myself this is the actual writer’s code.
Recommendation and References
As the title of this post suggests: I recommend reading Clean Code. I highly recommend reading it with a grain of salt though. If you just started programming, you are on your first year of CS bachelors or you just finished a coding bootcamp, there ‘s way more for you to learn from Clean Code than an experienced/professional coder AND / BUT , there’s more weight on you to double check the information you read, as this is a very OLD and outdated book that doesn’t necessarily match the current era. I would co as further as this reviewer on Quora asking you to ” just read modern books ” , but be very mindful about the information your digest while reading Clean Code.
If you are an experienced/professional coder, you’d probably end up writing a similar blog post after trying so hard to understand what was going on on Robert C Martin’s head when writing it. 😅
Finally, I’d say this post is just a reflecting on my experience reading Clean Code and the ups and downs I’ve been through when doing so. I’d leave some references / links related to Clean Code here.
Recent Comments