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.
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.
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.
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.
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.
Sorry, I still don't really get the hate.
Most of the good points are common sense.
I use what I learned from watching a talk by him on clean code and I had to learn some stuff. It might be "common sense" for experienced developers. But it certainly doesn't come naturally that "functions should do one thing" to first time coders. The thought processes of when the software was developed usually isn't the best way the code should be structured in the end. But that's usually how beginners code.
It’s mostly based on what he feels is good.
In most diciplines, experience in the field is what makes the knowledge of the field. You don't always have to be able to explain why good practice does what it does.
Also: I know of some examples, where he clearly explains his reasoning, e.g. why comments shouldn't explain how the code works. (Because they're not going to be updated, when the code will be)
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.
Either you misrepresent him, or you get a hard nope from me. Staying on one layer of abstraction is most likely my most important principle of writing understandable and maintainable code.
Which of these do you prefer?
A?
@Test
public void turnOnLoTempAlarmAtThreshold() throws Exception {
wayTooCold();
assertEquals(“HBchL”, hw.getState());
}
Or B?
@Test
public void turnOnLoTempAlarmAtThreashold() throws Exception {
hw.setTemp(WAY_TOO_COLD);
controller.tic();
assertTrue(hw.heaterState());
assertTrue(hw.blowerState());
assertFalse(hw.coolerState());
assertFalse(hw.hiTempAlarm());
assertTrue(hw.loTempAlarm());
}
Uncle Bob's Clean Code suggests
Option A
Regarding the experience thing, I’d like to point out that a lot of us have experience that says „clean code” is a real pain in the ass to work with and think through.
You do? I have the opposite experience: I regularly stumple over dirty code where levels of abstraction differ wildly and I regularly lose my train of thought, because some function writeToFile() all of a sudden shifts some bit in a register with an outdated comment next to it (overly dramatizised).
Functions never being longer than 4 lines goes, too far IMHO, but the "clean code should read like prose" bit is something that has been really useful to me.
Functions never being longer than 4 lines goes, too far IMHO,
That's the problem with the book! People experienced enough to sort out bad advice from it are already experienced enough to have learned the good advice.
Im not saying every word of it is wrong, just that the sum total of all his advice is. I don’t think there’s any school of thought that says it’s good for a function named ‚writeToFile’ to be doing other stuff
My (poorly chosen) example wasn't about the side effects, but rather about the differing layers of abstraction. Almost all criticisms I've seen was about the "functions should be like only 4 lines" rule. Which admittetly: Is a bit whack. But no one actually pulls that rule through, do they?
I think the focus on short, simple functions combined with DRY code leads to many early, poorly chosen abstractions. Getting out from under a bad abstraction can be painful.
why comments shouldn't explain how the code works
I categorize this as one of the better points of the book.
functions should do one thing
I kinda disagree with him on this point. I wouldn’t necessarily limit to one thing, but I think functions should preferably be minimal.
Throughout his examples he’s also using ideas like how functions should only be 3 lines long, preferably have no arguments, and also no return values.
This style of coding leads to programs that are nightmarish to work with. The relevant code you’re looking for might be 10 layers deep of function calls, but you don’t know where. You’re just jumping between functions that does barely nothing until you find the thing you’re looking for, and then you need to figure out how everything is connected together.
I prefer when things are flatter. This generally leads to more maintainable code as it’s immediately obvious what the code is doing and how everything is connected.
I think his book is the equivalent of a cleaning guide where all the steps are just to sweep all the mess under the carpet. It looks cleaner, but it’s not clean.
People can take the "do one thing" argument too far. I've seen people have individual micro services for each CRUD action on a resource.
I kinda disagree with him on this point. I wouldn’t necessarily limit to one thing, but I think functions should preferably be minimal.
I do actually agree with him on that point - functions should do one thing. Though I generally disagree on what one thing is. It is a useless vague term and he tends to lean on the smallest possible thing a thing can be. I tend to lean on larger ideas - a function should do one thing, even if that one thing needs 100s of lines to do. Where the line of what one thing is, is a very hard hard idea to define though.
IMO a better metric is that code that changes together should live together. No jumping around lots of functions or files when you need to change something. And split things out when the idea of what they do can be isolated and abstracted away without taking away from the meaning of what the original function was doing. Rather than trying to split everything up in to 1-3 line functions - that is terrible advice.
Yeah, that’s an argument of semantics. I agree with you.
What I believe is that functions should do exactly what they advertise. If they do the things they’re supposed to do, but also do other things they’re not supposed to do, then they’re not minimal.
But I feel like Uncle Bob is leaning more towards that if a task requires 100 different operations, then that should be split into 100 different functions. One operation is one thing. Maybe not exactly, but that’s kind of vibes I get from his examples.
Yeah. I get more of what you're saying now. The 3 line functions on principle are indeed a bit much. Although I've found that sometimes theare necessary to stay consistent with the layers of abstraction (e.g.: a for-loop that writes some data over some bus).
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.
He realized he couldn’t polish a turd.
"I'm driven by the hope that I haven't made my best work yet" ~Paula Scher
He's just refactoring it
But is he rewriting in Rust?
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
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.
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.
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.
That's fine, and for that there are sum types. My own opinion differs - it's a question of taste. Being able to bundle the handling of exceptional situations aside from the straight-line logic (or use RAIi-style cleanup) is notationally convenient.
Yes, you can do the same with monads; use the tools available to you.
The real joke here is that after causing millions of pointless refactorings and rewrites, now finally the source book is affected as well.
I mean he’s walking right into this isn’t he!
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.