Hacker News new | past | comments | ask | show | jobs | submit login

The article’s argument is a reductio ad absurdum that flows from the outcome of the purportedly reasonable refactoring of this:

  int new_sequence_number (int old_sqn, int foosoft)
  {
      if (foosoft == 2) // version 5.34.2 of the protocol
          return old_sqn + 3;
      else if (foosoft)
          return old_sqn + 2;
      else
          return old_sqn + 1;
  }
into this:

  int new_sequence_number (int old_sqn, int step)
  {
      return old_sqn + 1 + step;
  }
The problem is that this isn’t reasonable. Though the function signature looks the same, foosoft is an enumeration of some kind but step is actually an integer— This sort of change requires an audit of all call sites, as the meaning of one of the arguments has changed.

One big red flag here is that the new function body isn’t what you’d expect from its signature. Why is the sequence number incremented by step+1 instead of step? The only reason I can think of is that they want to maintain compatibility with an old callsite, but that doesn’t make sense with the category change of the argument.

Ideally, the function signature itself should change so that the compiler will point out all of the obsolete usages to you. If you can’t do that with the type system, change the function name.




You have to grant some grace to blog posts trying to demonstrate software architecture issues. Neither you nor I nor anybody else would read the blog post if it had a realistic 10,000 line example. No software architecture issue truly manifests at blog-sample sizes, because software architecture just isn't an issue in the dozen-line range.

(And that one person proving me wrong and reading the 10,000 lines would then proceed to nitpick endlessly on yet more details irrelevant to the blog post's point....)


Aside from the flaws of his counter-example, he’s trying to argue in support of a technique that he gives no example of whatsoever. He simply states that his preferred solution would handle the inherent complexity better than this.


That the refactored version tries to perform math using the value of an enumeration also makes this feel unrealistically absurd.


What you're attacking is IMHO just a part of a side-note of the actual argument; sure, that's a bad way to refactor the function. But even with an appropriate refactor, the codebase as a (fragmented) whole remains less readable and maintainable than a long spaghetti function potentially is.

Because the problems now cut across responsibilities of the components built on certain assumptions made for the sake of removing the spaghetti. Because now you need to account for "global" parameters (protocol version) in lots of disparate "local" scopes - individual functions who are quickly losing their degree of encapsulation.

We're discussing a hypothetical code-base, so focusing on the details isn't probably going to be too helpful. In any case however, I in no way see how the argument "flows from the outcome" of the refactor you're focusing on.


By using a hypothetical to support his argument, the author is implicitly asserting that his hypothetical is representative of the real-world situations we’re trying to discuss. He had the freedom to pick the strongest example possible, or several varied examples, and chose to use only this one.

Specifically, he’s using the failed outcome of this hypothetical refactoring to argue that new_sequence_number should never have been broken out into a separate function in the first place because it separated the foosoft==3 case from the conditional, which made the bad refactor more likely to happen.

Certainly, in this hypothetical 1500-line function, it’s possible that they would have appeared close to each other and it’s possible they wouldn’t have. In this particular case, it’s entirely possible that the refactor was made easier to execute successfully because the programmer can leverage the compiler to find all the locations that need to be updated.

In the end, he’s demonstrated a flawed hypothetical procedure and asserted that it’s worse than an imagined alternative. As usual, the argument being unsound doesn’t mean the conclusion is incorrect, only that it hasn’t been demonstrated here.


> even with an appropriate refactor, the codebase as a (fragmented) whole remains less readable and maintainable than a long spaghetti function potentially is

Personally (anecdotally), I don't believe that this statement is true. In my experience, an appropriate refactor will always be more readable than any spaghetti code. I may be wrong, your statement may be true, but without good examples of such refactors, who can say.

The above commenter is just pointing out that the example given in the article is absurd. Which it is. And with that, the argument is lost.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: