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.

[–] Prunebutt@slrpnk.net 14 points 3 months ago (3 children)

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.

[–] ByteOnBikes@slrpnk.net 13 points 3 months ago

It’s mostly based on what he feels is good.

One of my main issues is, seeing his code in the past decade... It feels like this guy hasn't coded in a collaborative environment in years.

His personal opinion tends to get on the way with code that's easier to read from a team perspective. And "Uncle Bob" pushing that as the defacto way to code.

This happens from Influencer types who are so detached from the industry for decades and are no longer aligned with problems real engineers hit.

It's not that he's wrong. It's that his perspective is outdated.

[–] magic_lobster_party@kbin.run 10 points 3 months ago (4 children)

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.

[–] nous@programming.dev 9 points 3 months ago (1 children)

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.

[–] magic_lobster_party@kbin.run 8 points 3 months ago (1 children)

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.

[–] nous@programming.dev 4 points 3 months ago

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.

Oh yeah he defiantly does. He even says so in other advice like a function should be about 1-3 lines. Which IMO is just insane advice.

[–] JackbyDev@programming.dev 5 points 3 months ago (1 children)

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.

[–] NigelFrobisher@aussie.zone 3 points 3 months ago

This, but with separate services for read and write operations and another for event handling.

[–] vrighter@discuss.tchncs.de 3 points 3 months ago

also, the dependency inversion thing makes it so that not even the tooling can help you with that, to put the cherry on the cake

[–] Prunebutt@slrpnk.net 3 points 3 months ago

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).

[–] JackbyDev@programming.dev 9 points 3 months ago (2 children)

Which of these do you prefer?

@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

[–] magic_lobster_party@kbin.run 8 points 3 months ago (1 children)

I almost pulled my hair out when I read that section. One is super obvious without any prior experience with the code. The other is an obscure abomination only he can understand. He’s obviously super proud of his abomination and thinks it’s a prime example of “clean code”.

[–] JackbyDev@programming.dev 7 points 3 months ago

It's also a good example of how being too dogmatic about function length can hide important details.

[–] RonSijm@programming.dev 3 points 3 months ago

I've started to prefer option A to be honest.

In C# I'm using Verify - So I prefer to just use Verify(state); and compare the entire state against a json saved state, instead of manually verifying every individual property

[–] pkill@programming.dev 6 points 3 months ago

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.

[–] ByteOnBikes@slrpnk.net 32 points 3 months ago* (last edited 3 months ago) (1 children)

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.

[–] Prunebutt@slrpnk.net 13 points 3 months ago

Thanks. Didn't know the last bit. Ffs =.=

[–] asyncrosaurus@programming.dev 28 points 3 months ago (1 children)

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.

[–] bleistift2@sopuli.xyz 6 points 3 months ago

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).

[–] JackbyDev@programming.dev 9 points 3 months ago

This is the article that convinced me to never read this book. https://qntm.org/clean

[–] noproblemmy@programming.dev 6 points 3 months ago

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.