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.

[–] [email protected] 3 points 3 months ago (23 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.

[–] JackbyDev 12 points 3 months ago (6 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

[–] RonSijm -1 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

load more comments (5 replies)

load more comments (21 replies)

load more comments (28 replies)