Rule 23 of 38 · Chapter IV — Write for the Next Developer
Keep functions honest about their size
Why this rule exists
A function's length is a rough proxy for how much you must hold in your head to understand it. When one function does five things, you cannot reason about any one of them without the other four, and every change risks the parts you weren't looking at. Small, honest functions each do one nameable thing, which is what makes them testable and safe to change.
In practice
When a function grows past what fits on a screen, ask what distinct jobs it is doing and give each its own named function. Watch for the seams: comments that announce a new phase, or blocks separated by blank lines, are usually extractable functions asking to be born. Name each by what it accomplishes, not how.
When it doesn't apply
Length is a smell, not a sin. A long function that is genuinely one linear sequence — a parser, a state machine, a switch over many cases — is often clearer whole than chopped into fragments you must reassemble mentally. Don't split just to hit a number.