It can be the exact opposite too (which is why a shorter as opposed to longer function is a tradeoff that should be questioned each time, as opposed as a clear winner).

A 250-line function might better encapsulate the required logic to understand a piece of code.

1 function composed of 10 20-line functions might requiring hunting around to get the point and understand the big picture, with everything always happening "somewhere else".

Nope. All the methods should clearly name the functionality. No guess work. It reads like prose.

I respectfully disagree. If those functions are only used in this one place, I'd much prefer to have the code in one large block. John Carmack makes a good argument for why: https://news.ycombinator.com/item?id=25263488

I have worked on code bases where they followed the 20 line per method rule religiously. It resulted often in artificially broken up functions that were way harder to read than one big function. I would call it "small function spaghetti code".

So don't artificially break them up?

Refactoring a larger function into a group of small ones doesn't come for free. Even though it might often be a good idea, when it's not done with care it can confuse, not clarify. It comes down to a matter of judgment of the whole and deliberate expression. That's contextual, not absolute.

With that said, I somewhat agree with the spirit of what you are saying. I tend to lean in the direction of smaller methods when possible because they often make things more readable and more explicit.

If it isn't clear it's not easy to change, making it "bad code."

Do what needs to be done to make the intent of a block of code super clear, in plain English. Comments don't count, as illustrated clearly in The Pragmatic Programmer, for instance.

As much as I like this idea in theory, in practice, a lot of the hairiness and opacity of code I've seen comes from the business domain itself, not the code. There is only so pretty you can make code which has to do painful and unintuitive tax calculation, or credit underwriting logic. But often times, this code is the most critical to the business as a whole. It is code which is counterintuitive because it reflects a reality which is itself painful and unintuitive.

When it comes to writing clear code in reality, I'll repeat what I said before -- there aren't absolute rules, and things are contextual. Where it's possible, it's absolutely ideal to keep things compact and expressive. But that only will take you so far. When you run into domain logic that is to an extent incompressible, trying to compress things further will only impede clarity.

The rule of thumb of 80 chars, which was(sometimes still is) applied for width, also applies for height: a function should not be more than 24 lines :) If it is greater than that then it needs to be refactored. Helps in readability as one does not have to scroll to read the entire function. Of course these rules came into being when terminals were 80wx24h. This was a guideline for Linux kernel developers for many years.

I think strict adherence to such rules is silly. Some 20 lines functions are massively more complex than some 120 line functions.

If the computation is simple and linear, then long functions are fine. If there are nested loops and if statements and other forms of flow control and deep nesting, then long functions are painful.