Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
The real joke here is that after causing millions of pointless refactorings and rewrites, now finally the source book is affected as well.
grug even have whole section just for refactor code
inexperienced big brain developer see nested loop and often say "O(n^2)? Not on my watch!"
complexity demon spirit smile
This hits too close to home.
New code is O(n log n), but the time benefits only kicks in when n is above 1 trillion. Otherwise it’s much slower.
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
Finally, a development philosophy that sounds unambiguously correct.
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.)
Ahhhh, the ol' "dynamic languages are better than static languages because I have tests that check for different types" argument.
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 any when writing Typescript.
For example, in Swift, if you declare a function to throw an exception, then by God every call to that function, all the way up the stack, must be adorned with a do-try block, or a try!, or a try?
I agree with him on this point. Sounds similar to how it’s in Java, and I hate it. I always wrap my exceptions in a RuntimeExceptions because of this.
I disagree with him the rest of the post. The job of the programmer is to communicate the intent of the program. Both for others and for yourself. The language provides the tools to do so. If a value is intended to be nullable, then I would like to communicate this intent. I think it’s good when a language provides this tool.
Tests don’t communicate the intent of the code. Tests can’t perfectly validate all the possible edge cases of the system either.
Checked exceptions are powerful but misunderstood. Exception types are a useful part of the facade to a module - they express to a caller how it can go wrong even if used correctly.
Runtime exceptions are typically there to express contract-breaking by callers; although as an alternative return mechanism I've seen them used to simplify the inner workings of some frameworks.
I think they get a bad rep because there aren't a ton of good examples of how to use them - even the java classpath had some egregious misuse initially that helped turn people off the key ideas.
Imo, if a method require the caller to do error handling, then that should be part of the return value. For example, use optional or either. Exceptions shouldn’t be part of any expected control flow (like file not found). Exceptions is an emergency panic button.
His take strangely acknowledges that defects are caused by programmers, yet doesn’t want to improve the tools we use to help us not make these mistakes. In summary, git gud.
Experience has taught me that I’m awfully good at finding and firing foot guns, and when I use a language that has fewer foot guns along with good linting, I write reliable code because I tend to focus on what I want the code to do, not how to get there.
Declarative functional programming suits me down to the ground. OOP has been friendly to me, mostly, but it also has been the hardest to understand when I come back to it. Experience has given me an almost irrational aversion to side effects, and my simple mind considers class members as side effects
To my knowledge, the Rust's book actually encourages writing as many automated tests as you can, as the compiler can't catch every type of bug in existance.
rather strongly typed Java.
[In Java] you can also violate many of the type rules whenever you want or need to
Okay. Well maybe being able to not spell out types every single time would also count as not burdening the programmer ¯\_(ツ)_/¯
I bought Clean Code when I started learning programming, some of it was useful, but now I understand that it was too opinionated for a beginner
Edit: also
Whose job is it to manage that risk? Is it the language’s job? Or is it the programmer’s job[?]
It is language's job to enforce risk management wherever possible, humans are demonstrated time and time again to be poor at risk management (same for the other questions like 'whose job it is to check for nulls'
Edit2:
Defects are the fault of programmers. It is programmers who create defects
… and that is why he proposes to not help programmers with language means. I never thought that views of how problems should be tackled might differ so much while having in mind the same reasons and goals.
Albeit I do agree that one must write tests, even if language helps, not everything can reasonably be automatically checked
You can write an unmaintainable fucking mess in any language. Rust won't save you from cryptic variable naming, copy-paste code, a complete absence of design patterns, dreadful algorithms, large classes of security issues, unfathomable UX, or a hundred other things. "Clean code" is (mostly) a separate issue from choice of language.
Don't get me wrong - I don't like this book. It manages to be both long-winded and facile at the same time. A lot of people seem to read it and take the exact wrong lessons about maintainability from it. I think that it would mostly benefit from being written in pseudocode - concentrating on any particular language might distract from the message. But having a few examples of what a shitfest looks like in a few specific languages might help
Honestly, a pretty fucking hilarious take. I wonder if he's publishing a new book because the old dead tree format was boring and there's some new crystal inscription system he read about on the forums.
if your function has more than four inputs, remember that uncle bob knows where you live
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.
I genuinely think his book is rubbish. I agree with some of his points. Most of the good points are common sense. For the most part I heavily disagree with the book.
Throughout the book he has examples of programs where he shows before and after he applies “clean code”, and in almost all examples it was better how it was before.
I can write a lot about why I don’t like his book. He doesn’t make many compelling arguments. It’s mostly based on what he feels is good. He often contradicts himself as well. If I remember correctly, he has a section about how side effects are bad. I agree with him on this part. Shortly after, he proudly shows an example of “clean” program - and it’s littered with awful side effects!
He also has this weird obsession of hiding the logic of the program. As a programmer, I want all relevant logic of a method to be neatly collected in one place - not scattered around deeply nested method calls.
I can go on and on. I hate this book with a passion.
I think it’s telling that none of his talks even make it all the way through his SOLID acronym, he sorta just trails off when he’s out of time.
His ideas were real big in the ruby community back when I was learning it, and if I ever go back that code is such a pain to work with. Almost impossible to follow the logic, inheritance everywhere, and I even thought metaprogramming was a good idea. Tests are the only reason that code has any reliability at all.
Now most of my code is procedural or functional, favors composition over inheritance, and is colocated as much as possible.
Fucking Ruby... Nothing is more confusing to me than seeing an error about a method not existing but the problem being that something was null/missing.
death by specificity is a thing...
HTTPServletRequest has a fuckton of methods but 90% of them could be eliminated if one treated the data as a simple fucking map instead of creating 4 methods for each key in every record of your schemas.
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.
Thanks. Didn't know the last bit. Ffs =.=
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.
While we’re giving advice on good reads, I foudn “Code Complete” to be much more useful than “The Pragmatic Programmer” (also about 10x the size).
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.
personally I'd sum it up this way: it is usually enough to abstract two parts of your code: the repetitive stuff and the stuff that can be separated from external dependencies like db or network. That should be enough to ensure readability and that you can test it properly and not have to deal with rewriting half your codebase when you decide to change an external dependency.
I take it as people just joking. Personally I'm in doubt if the tweet is serious and the new book is true, or is it just a joke about refactoring/re-writing code.
Well engineered and 'clean code' are two different things. You will know when you look at it.
A well engineered codebase will always be modularized with time (-10 years)
He's just refactoring it
I mean he’s walking right into this isn’t he!
"I'm driven by the hope that I haven't made my best work yet" ~Paula Scher