Timothy Lochner

But then you see an entire codebase of 1-line functions (hyperbole, I know). The opposite side you see these monstrosities that are hard to follow. Occasionally a pragmatic engineer is capable of writing a good monster function, but it takes discipline.

In Task Based Programming (at least, the variety I'm doing), the "size" of a function has real meaning, because each function is (usually) a task. Your function length and design becomes determined by profiling. Seeing core usage drop? Might be that function is too "big".

Spending a lot of time in task overhead? Tasks are too small: try batching work together (which may take some re-organization). For this, many small loops is better than 1 loop that does many things (parallelizes better).

For "helper" functions, which in this context are functions that are not themselves a task, but called by tasks, you can still run into the danger of 1-line-per-function codebases. I'm generally not in that camp of "ideal function size" so not a problem here.

Here's the larger point, I think. Lots of things come down to preference in programming. It's nice to have a "preference" made clearer by something that the machine cares about. I wonder how many more "preferences" there are like this that we haven't found yet.