Spaghetti code refers to the complexity of tracing cause/effect through a set of routines increasing to the point where you can no longer safely add functionality or fix bugs without too high a risk of regressions. It has to do with the difficulty of understanding the purpose, intent, actions, and side-effects of each function.
As is often the case, splitting a function too much simply based on a LOC guideline can result in spaghetti code just as easily as it may guard against it. Functions should be atomic, re-usable, repeatable, clearly defined, and well encapsulated.
I don't see lines of code as a direct factor in judging a function implementation, as long as those lines are spent moving the feature forward and not violating "DRY".
And when they're very long, it's a warning flag indicating that they may NOT be atomic, re-usable, repeatable, clearly defined nor well encapsulated.
Also bear in mind that code is not carved in stone, but subject to constant change in every project that isn't deprecated, let alone in one under active development. This is why we judge its design not only by what qualities have been achieved up to this point - but also by whether the design serves to prevent them from deteriorating.
A long function that's reusable at the moment is at much greater risk of becoming unreusable than a concise one.
Readability is of great importance, too, since code is meant to be read by humans.
Note that the author himself kindly replied to my comment and admitted that he's going to refactor - https://news.ycombinator.com/item?id=8908307
Poor readability and messiness is acknowledged as an issue at the moment, since it is (to quote https://github.com/shurcooL/Conception-go/issues/3) "hurting readability of the project for other people". What else is poor code readability if not (to quote your words now) "difficulty of understanding the purpose, intent, actions, and side-effects"??
> I don't see lines of code as a direct factor in judging a function implementation, as long as those lines are spent moving the feature forward and not violating "DRY".
Well, in this case we have to agree to disagree I guess :)
