The real joke here is that after causing millions of pointless refactorings and rewrites, now finally the source book is affected as well.
But is he rewriting in Rust?
Unlikely, unless his view has changed substantially in the last seven years: https://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath.html
I think his views on how to achieve good quality software are nearly antithetical to the goals of Rust. As expressed in that blog post and in Clean Code, he thinks better discipline, particularly through writing lots and lots of explicit unit tests, is the only path to reliable software. Rust, on the other hand, is very much designed to make the compiler and other tooling bear as much of the burden of correctness as possible.
(To be clear, I realize you’re kidding. But I do think it’s important to know just how at odds the TDD philosophy is from the “safe languages” philosophy.)
This is an absolute terrible post :/ I cannot believe he thinks that is a good argument at all. It basically boils down to:
Here is a new feature modern languages are starting to adopt.
You might thing that is a good thing. Lists various reasonable reasons it might be a good thing.
The question is: Whose job is it to manage that risk? Is it the language’s job? Or is it the programmer’s job?
And then moves on to the next thing in the same pattern. He lists loads of reasonable reasons you might want the feature gives no reasons you would not want it and but says everything in a way to lead you into thinking you are wrong to think you want these new features while his only true arguments are why you do want them…
It makes no sense.
Yeesh, I thought you were being hyperbolic, but it really is that bad! He even has this massive self report towards the end:
And how do you avoid being punished? There are two ways. One that works; and one that doesn’t. The one that doesn’t work is to design everything up front before coding. The one that does avoid the punishment is to override all the safeties.
And so you will declare all your classes and all your functions open. You will never use exceptions. And you will get used to using lots and lots of ! characters to override the null checks and allow NPEs to rampage through your systems.
Uncle Bob must be the kind of guy who makes all of his types
anywhen writing Typescript.
Ahhhh, the ol’ “dynamic languages are better than static languages because I have tests that check for different types” argument.
grug even have whole section just for refactor code
I feel like this is a perfect encapsulation of how an experienced self-aware developer thinks. Experience really beats the hard stances out of you. I find myself saying “it depends” and “a bit of column A, bit of column B” often, like a cheap kids toy
Programming is the gradual collection of mantras.
I don’t really get the hate he gets in the other comments. Are you all joking, or can someone elaborate? I always liked what I’ve read/heard of Bob.
Personally I have been around longer than him but I used to like his stuff at first.
As I’ve coded more and more on stuff that is built not only on legacy code but specifically legacy code by coders influenced substantially by clean code… damn has this single author given me a headache like nothing else ever has.
The level of inane unmaintainability and complexity achieved by younger coders being encouraged or forced to code “clean” is remarkable.
Can you give examples? I genuinely can’t think of how the principles applied with proper restraint not to overdo it make code hard to maintain. But I’ve only watched his talk a few years ago - not the book.
There are a fair few examples in the book itself. https://qntm.org/clean
I’m not as much vitriol as others about Clean Code, but I will argue that engineers who preach the book as some sort of scripture are really obnoxious.
I love the Single Responsibility Principle, in theory.
What I don’t like is when devs try to refactor everything to that idea to achieve “Clean Code”. I’ve seen devs over-architect a solution, turning one function into many, because they don’t want to break that rule. Then point to this book as to WHY their code is now 20x longer than it needs to be.
It also doesn’t help that every recommendation about good programming books include this.
It’s like recommending a Fitness book from the 70s - information made sense at the time, but new research has made a lot of the advice questionable.
My main issue is the whole “Uncle Bob” persona. Robert C Martin is sexist and a racist, and has been uninvited by conferences. We don’t need that type of toxicity in the industry.
It’s a beginners book filled with a mix of bad and good advice, which takes considerable experience to separate the two. Those who can point out all the bad advice already don’t need the book, and newer developers will pick up absolutely atrocious coding advice. There’s simply better books that target beginners better, like The Pragmatic Programmer.
So when you are on-boarding junior devs that have bought into the clean code/SOLID dogma, you’re spending several months beating all their terrible coding habits out of them.
This is the article that convinced me to never read this book. https://qntm.org/clean
