Is Clean Code book really good? I have found some discussion previously:
It is debatable if Clean Code actually improves the programmer efficiency and programs readability. I find people applying it religiously often create over-complex designs like FizzBuzz Enterprise.
Even Uncle Bob’s examples are not the state of the art in readability: It's probably time to stop recommending Clean Code @ Things Of Interest
The main problem seems to be that Clean Code is mostly a premature optimisation in code flexibility. It makes code more complex and objectively worse in hope it would be easier to extend later. Unfortunately we often dont know how the code will change, and in practice the code has to be significantly changed/rewritten anyway when a business requirement change appears.
IMHO optimizing for simplicity and readability has served me the best. Instead of avoiding the changes in code, it is better to write code so obvious that anyone can safely and easily change it when really needed.
And finally, performance of the program vs performance of the developer is a false dichotomy. So many times I’ve seen a more readable, simpler code turned out to be more efficient as well. You often can have both.
Yes, there has been some pushback to Clean Code and the SOLID principles. I’ve seen this kind of thing over the course of my career (anyone still using Hungarian notation?) There is “the way you should do it”, but, given enough time, “the way you should do it” changes. It could be said that a programming language is like a natural language in that either it lives as it is constantly modified by its speakers (or writers) or it starts to become a dead language used only by a coterie.
Still, there are some things I’ve seen stick around, like minimizing the use of NULL (or eliminating it completely) and minimizing the use of GOTO (it can still sometimes be handy for going to cleanup sections of code in some languages, but that’s about it.)
On page 71, I realized I was not the problem. He provides an example of “bad” code which needs refactored, and provides a refactored version. The example is a prime generator program.
The original code is a single static function, using local variables. Not a particularly long method. The refactored version is several functions, sharing state with static fields.
The reason I decided to abandon the book entirely at this point was because the “refactored” code was literally broken.
The original code was thread-safe; the new code is completely non-reentrant, and will give erratic or wrong results if used on multiple threads.
When I started to read about code, I was very soon presented to read Clean Code by “Uncle Bob”. And I read some part of it. I think there are a bunch of good things in Clean Code, but these are very general considerations. They are not super specific about Clean Code.
Then I saw Uncle Bob solve some Advent of Code exercise live. WIth a lot of TDD. I have watched other people solve AoC exercises and I got a lot from them. With Uncle Bob I mainly thought: “Wow, when does he start to tackle the problem. That is a lot of tests and so many tiny functions. Is this how professionals structure their day to day?”.
I mostly forgot about that experience. Until I came to exercism and saw bobahop on the site. My first thought was: “Please, let that be another Bob, I don’t want to read through all those tests”
Edit:
I wanted to see if I could find that video. I could not, but I found his 2022 AoC solutions that are written in Clojure. A language that can be very, very concise. I love that part of Clojure. I took a random one and he had more than 180 locs and the commit is flagged as “easy peasy”. I also solved that one - in Elixir. And I was 13 days into the language back then. I used a quarter of that. If that is what Clean Code looks like, it feels very bloated to me and not fun to read.
In either the second or third video below, Brian Will shows some overly complex UB code, IIRC: (Edit, UB code starts at about 19:40 in the second video)
