Hacker News Reader

Comment by ajuc | Hacker News Reader

The biggest problem are relations between the functions.

In one function control flow is so simple we don't think about it. It's sequence. In 100 functions either each call the next one (and even if the 100 functions are placed in calling order I cannot assume that when reading the code - I must do 100 ctrl+clicks to see the control flow), or there's another function calling all of them (but what's the point - we still have 100-line function that way), or there's some more complicated calling sequence and I have to draw it somewhere to understand it (sorry, can't keep 100 things in my head at once).

To understand the code I have to follow the control flow through these 100 function. I don't think any 100 lines of code in one function can be harder to read than that.

View on HN

And this is where meaning is relevant. Good naming is important to convey the level of abstraction. What you describe is as if you were to compare the functioning of, say, the liver, by looking at its cells. Proper naming conveys what you are looking at and you can chunk things together. If all the functions are named at the same level of abstraction, of course the code will be much worse to read.

If all the names are just a and b, well, of course it is harder to follow the flow of a program because the use and meaning of the functions has to be infered by their definition. Good names help identify paths of flow, but I rarely see this separation in a clear way, resulting in the problen you describe.

Even with perfect naming you have to jump down to the bottom level to see the details. And details are the only thing that matters in the end.

You can't put all the details in the name of the main function (otherways just change the name of that 100-lines-long function and keep it - if it can be named perfectly (and shortly) without skipping any details - it's OK as it is, no matter the size).

I'm afraid you're talking about procedures returning values rather than functions. If so, then agreed.

But 100 (pure) functions might be much easier to understand than a 100-line function with many loops, branches, jumps and complex internal state mutations. Assuming no recursive or mutually-recursive calls, you can convert 100 one-line functions to a flat function (no nesting, no loops) with 100 expressions.

Another difference in readability is in order - with 100 functions the order of evaluation does not matter, and with a 100 loc imperative procedure, the order of evaluation does matter and is additional thing to keep in mind.

That's a big assumption. I don't think I've ever seen 100-lines long function with no dependencies between the 100 lines of code... Maybe in a constructor which calls 100 setters? Which is another great example why turning long functions into sea of one-liners isn't always a good thing.

Reply on news.ycombinator.com