Whatever 'Clean Code' you write now, it'll be shit eventually and in need of a complete rewrite

RonSijm@programming.dev to Programmer Humor@programming.dev – 569 points –
90

You are viewing a single comment
View all commentsShow the parent comment

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());
  }

::: spoiler Uncle Bob's Clean Code suggests Option A :::

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

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

Why in the holy mother of rust is A the better option?

His idea is that it’s faster to read that short string once you learn how to read it. But then you need to learn how to read it.

In my experience, every time I thought of something clever like this, I’ll almost always regret it a month later when I revisit the code.

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