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

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: