Hacker News Reader

Comment by cessor | Hacker News Reader

Making use of "chunks" makes code better to read. A function is essentially a proper chunk (whereas a comment is a bad way to do the same thing). Depending on the paradigm, I usually enjoy code that has tiny units, but many of those - i.e. a function with 100 lines is harder to read than 100 functions with one line each. Ideally each name adds proper meaning to the code so that the intent becomes clear. Code like this is usually easier to change, reuse and test (tdd).

This can go the wrong way - many people mentioned how too many abstraction layers in big java projects are a pain, and I agree, as they often make the code more meaningless and abstract, rather than concrete. Oh yeah and pattern names do the same thing.

View on HN

> i.e. a function with 100 lines is harder to read than 100 functions with one line each.

I understand where you come from, but I disagree with that particular example. 100-lines long function is harder to read than nessesary, but can be understood without problems.

100 functions doing the same work will be a nightmare to keep in head at once, at least for me. If you refactor one function into 100 you're not doing it right.

In this case (of 1 function split into 100) each of them is probably used exactly once. The effect on readability, especially if they are defined in an order of execution, is similar to placing a comment (function name and args and return value) next to every single line in the 100 line function. No matter if the comment was actually needed or not there. So I agree, it will probably result in worse readability than keeping the function as one, but commenting sections of it and extracting only repeated patterns into separate functions.

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.

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