Don't Refactor Like Uncle Bob

If anything, I would go in the opposite direction. There's no need to use parameterized variables at all. Just write out the message 3 times:

  private String generateGuessSentence(char candidate, int count) {
      if (count === 0) {
          return "There are no " + candidate + "s";
      } else if (count === 1) {
          return "There is 1 " + candidate;
      } else {
          return "There are " + count + " " + candidate + "s";
      }
  }

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

Weird. My impression was that hating on uncle bob had made for low hanging blog fruit for a good 5 years already.

Some of CC is alright (I have a feeling he popularised negative gates and early returns?), some of it didn't age as well. As is often the case it's hard to see it in the context of its time.

So I started to refer to Clean Code when I needed an authority argument: if it’s in a book, you need a stronger argument against it, and unless you have a sound argument, your code is unclean.

I believe Clean Code mostly gets referenced by people who look for someone to agree with them on anything specific. The weaker opinions and examples become “junk DNA” for a selective quoter.

Back then, I often didn’t find a section where Clean Code agreed (or disagreed) with me. Mainly because I got influenced by functional programming, which the book does not address.

Once I decided to read the whole book, because I wanted to collect the good parts. I found myself only disagreeing in a small number of sections. But at the same time, I was completely unable to use his examples for anything.

I think this book serves a purpose. But I don’t think it addresses enough of what I have learned in the last ten years.

A simple example is naming things: the book does a fine job at giving good and bad examples. But I find that once you find the right vocabulary from your problem domain, and you want to choose among words that are all appropriate, thoughts like “is this at the right level of abstraction for this area of the code?” and “will this name also be meaningful in 6 months?” don’t get addressed. It’s the scenario where all your choices are okay, which name is better?

The book played a big role on my early career before I gained an authority and an experience of my own.

Usually when this happens, people are dismissing a toy example, (and they can make the toy even simpler.) I think that is the case here.

String-concatenation in a word game is not worth this abstraction overhead. But I think it's supposed to teach people not to be afraid of usingLongFunctionNamesToTellAStory().

It would probably work better on code like:

  ..
  // Otherwise we gotta make a sibling now
  if ( newNode (&siblingId, a) == NEWNODE_FAIL ) {
    return ADD_FAIL;
  }
  Node *sibling = getNode (a, siblingId);
        
  // And a new place for it to point
  NodeIdx destId = 0U;
  if ( newNode (&destId, a) == NEWNODE_FAIL ) {
    return ADD_FAIL;
  }
  ..

  if (needSiblingNode()) {
    return ADD_FAIL;
  }
  ..
  pointToNewAddress()

Whenever I voice criticism of 'Clean Code', a lengthy, awkward and difficult conversation follow, where I must clarify that I don't dislike writing code that is 'clean', I dislike writing code according to the whims of some dude who wrote a bunch of random practices down in a book he titled 'Clean Code'.

It never goes over well, and my chances of success are inversely proportional to how technical the conversation partner is, and how much of an agenda has.

When a non-technical manager 'helpfully' suggest I adopt best practices from this book to improve code quality, a special kind of pain arises in my soul.

I know I'm not alone in this struggle, the ways of defeating this menace has escaped a generation of programmers.

Same goes for Agile.

So if the OOP class is confusing, it has not met its goal. One could also argue that functions "do one thing" to reduce complexity, and if that one thing is to return a string, your function has succeeded.

Ousterhout also writes about "deep" functions versus "shallow" functions. "Deep" referring to a function that does a lot, without the caller doing a complex series of functions to get the end result. So subjectively, a single function with a lot of logic would be "more correct" than a class with many shallow methods.

Uncle Bob has caused more wasted time and effort than any other “thought leader” except perhaps Martin Fowler.

His examples are absolutely terrible and really make me question how anyone can read more than a few chapters into this book and still think Uncle Bob is an expert.

It’s subjective. It’s easy to obfuscate code, really hard to make it “clean.”

Personal anecdote: our cto is hung up on making super tiny methods bc of this book. You can’t follow logic because you’re constantly hopping between tiny bits of code all over the project. It’s like trying to read a Wikipedia article that’s been condensed to one run on sentence with every word hyperlinked.

*Terms popularized by consultants selling books and consulting.

We use Clean Code in one of our classes here at the university. What I tell my students is that they should take every piece of programming advice, and form their own rationalized opinion about that advice. And no matter what you think the right thing is, half the internet is probably going to disagree with you.

What's important, is that you assess the situation, draw upon your knowledge to code up the "best" solution, and have an opinionated rationale for why you did it that way.

Five years from now, you're going to look back at all your college code and be amazed at how crap it is. But what's important is that by having these opinionated rationales for the work you do, you are continuously learning how to make your code better.

And you're doing it in a flexible way. Sometimes rules should be broken for the greater good.

```ts

  const pluralizePhrase = (noun: string, count: number) =>
    count == 1 ? `There is one ${noun}` : `There are ${count || "no"} ${noun}s`;

    private String generateGuessSentence(char candidate, int count) {
        return switch(count){
            case 0 -> "There are no " + candidate +"s";
            case 1 -> "There is one " + candidate;
            default -> "There are " + count + " " + candidate + "s";
        };
    }

I learned go this way. I don’t mean I learned the syntax I mean I learned how to structure the code. It’s just really well thought out and extremely pragmatic.

It’s a master class in “clean code”.

I could probably point you to some things he has said that might change that...

Compound booleans are super useful for cleaning up huge chunks of imperative code. I do it all the time, and it makes the function far easier to read (although the tradeoff is in debugging).

Internet: "But some of his minor ideas are wrong."

Me: "So you think it's wise to ignore his brilliant ideas because of a few nits?"

Internet: "He once invaded Poland."

Me: ???

(though part of me wonders if the "Uncle Bob hate" is actually a clever PT Barnum style marketing campaign for Clean Code)

This is healthy.

Applies to all advices, wisdoms and mottos.

I prefer the 'after' (not that I don't have complaints about it).

When I read 'before', I can't see any structure. I scan from top-to-bottom, get half-way down, think "wait, what?" and my eyes jump back up without me even consciously deciding to.

> The first thing you’ll notice is that Martin has taken a single, mostly PURE function (shout out to all the functional bros), and made a class out of it.

That doesn't make a good purity argument. 'Before' has a print. There is no way to test it apart from reading stdout (or god forbid, having your test harness somehow intercept/mock the print call). `After` has no such IO, it returns the String itself to make unit testing possible.

I despise mutability, but neither before nor after does any re-assignment, (only assignment.) So really, those fields should be marked 'final' and the 'private void' methods should be constructors or something... I'm not really sure about the 2008 version of whatever language he's using.