So I’ve decided to read “Clean Code” by Robert. C. Martin and write a little reading journal for every chapter. I love discussing coding practices with my friends (often to procrastinate work) and when it get’s controversial, this book is usually the culprit. I’m always on the anti-clean-code side of the discussion and I even went so far and wrote “clean code is not a great book” in my resume (the German version is a little more harsh).
And I DIDN’T EVEN READ THE BOOK.
Even I have a little integrity sometimes and I decided to fix this.
Obviously I’m going very biased into this, so I’ll at least try to be as transparent about it as I can. Here are my thoughts on the book before reading it:
I’m under the impression that the author is all about abstractions and shoving them everywhere where you could express something as a bunch of classes instead of a procedure. Statements like “Prefer polymorphism to If/Else or Switch/Case” are the ones I strongly disagree with.
The author (I think) demands functions to be at most a couple of lines long. To me this seams not only unnecessarily arbitrary but it solidifies my suspicion that he abstracts his code way too much and uses “function length” as an indicator for “bad code/design.”
The author is probably a “code should document itself” kind of developer. Of course it’s easy to write bad and misleading comments and it’s sometimes hard to keep comments and documentation in sync with the code but I think the “no comments” approach is not the cure. I suspect the author will go too far for the sake of moving documentation into code — probably by introducing abstractions and splitting methods and classes.
A guy named [REDACTED] once said “[…] everyone who reads it [Clean Code] starts writing weird code.” and instead of having a nuanced and well researched opinion I trust that statement and adapted it as my own opinion.
I once saw a YouTube video about the performance implications and read (only half) of the discussion between the author and the critic.
This video essay about OOP being bad made me rethink object oriented programming in general and seems to be the exact opposite of this book. I love this talk and I often rewatch it to adjust my perspective from time to time.
Even though I have strong opinions about this book already I’m not completely opposed to the authors approach to coding (which I might be straw manning anyway). In a recent Interview between ThePrimeagen and the author I actually got a little curious about how “textbook clean coding” could be like. I’ll try to go into this open minded but I might sit in front of the book with crossed arms and a frowning face, formulating a rant in my head before finishing a chapter. Well here we go …
Side note: I will not post whole code examples or quote large passages. I advice having the book at arms length while reading this.
I like the table of contents so far. Most chapters seem to be just one or a few pages long with a lot of code. Those chapters are probably very concise and to the point.