[fizlebit]

The post is right in that the example code is terrible, Uncle Bob's changes make it much worse, but also the suggested fix is also bad. I think this is better, but the whole thing is silly. Obviously you'd want to write a comment for the function that explains its weird behaviour.

  String getCandidateCountString(char candidate, int count) {
    if (count == 0 ) {
      return String.format("There are no %ss", candidate);
    } else if (count == 1) {
      return String.format("There is 1 %ss", candidate);
    } else {
      return String.format("There are %s %ss", count, candidate);
    }
  }

There are 3 as. lol

[fishtoaster]

This is pretty much what I've come to over the years. It kinda feels like the "IQ Bell Curve" meme:

Beginner: I'll just create an if statement with 3 clauses.

Middle: No! that's clearly a ton of duplication - it's bad code!

Expert: I'll just create an if statement with 3 clauses.

And I can see how people get to the middle position. People often tell beginners to eschew duplication. They learn to see any trio of similar-looking lines as a code smell and jump to refactor. It takes a few years of doing that and getting burnt by it before you can really differentiate "this is duplicative and would benefit from refactoring" from "this only looks duplicative, and is actually cleanest with the repetition in place."

[IshKebab]

I wouldn't say his suggested fix is bad - it's certainly better than the original. But I agree your code is even better. Except it has a minor bug - "There is 1 candidates"

[fizlebit]

:) yes. I saw that error and wondered whether someone would point it out. I think the author fails to acknowledge that the use of variables like "verb" just make the code much harder to understand than a string that reads mostly like English.

  question = "Is";
  object = "this";
  adjective = "easy";
  String.format("%s %s %s");

vs

  String.format("Is this easy");

The second is much easier to understand than the first, so one should be careful when pulling out too many variables.

Seems like someone should write a book called "Clean Code Done Right" that has actual good examples of code. Maybe Rich Hickey? The high level advice is good, code should be written as simply as it can be. Functions should have a small clear mission and it should be easy to argue that the function is correct locally. That is to say: a functions correctness shouldn't depend in a complicated way on other functions, just a reasonable expectation on the behavior of the functions it calls, and a reasonable simple description of its mission. Easy to state this objective often difficult to achieve in practice.

Maybe a book showing elegantly coded solutions to actually difficult programming problems would be good, e.g. a system with maybe the complexity of high performance sharded fault tolerant Redis. There would be a lot of interesting topics there.

[dwaltrip]

This is the way. Far easier to understand (and maintain!) than any of the other examples. Temporary variables are abstractions, must use them with care.