It depends. Have you ever read a parser made using combinators? It would be composed of hundreds of small, compact functions called "combinators" that all take the same input (a character or token stream) and produce the same output (a partial parse tree).

They are readable because you can look at any one part and understand what is going on. Referential transparency is important here, as you can be assured each combinator has no strange side effects. Composability is also important, as it gives you an idea as to what each function call does without having to look it up.

If your functions have side effects and 100 different interfaces, then yes, that's a mess and hard to understand. If your functions have predictable interfaces and are referentially transparent, then that's a completely different scenario.

I mean, pretty much every Haskell program ever is split between a number of clean small functions. But for someone who understands Haskell it's hardly unreadable. Quite the opposite.

As someone who regularly inherits functions that are 300 lines long, I'll take 20 clean small functions over that any day.

I am reading this comment section in disbelief. If I were into conspiracy theories, I’d think it’s a spontaneous collaboration to misguide developers and ensure continuous job security for those of us whom desperate businesses would have to hire to clean up and maintain Copilot-generated single-function spaghetti.

Modularizing code into focused units is a big part of how you end up with sustainable software (another important part is understanding the requirements).

One of the easiest ways to make code clearer is to have well-named single-purpose functions that are used in many places.

One of the easiest ways to obfuscate code is to have control flow obscured by hiding it in functions scattered around the codebase.

Getting the former without the latter can actually be difficult, particularly with large teams.

Only if said functions are illogically split along non-obvious boundaries. Very frequently, though, I find I can break down concepts to two-three statements in a way that makes it very concise. But also not a hard rule, because there are cases when long-and-drawn-out work as well.

Even logical splits impede readability, because they require tracking and navigation during reading. Every new API has a cost.

I agree. If a function is only ever likely to be used in the one place it was pulled out of, you're probably better off just using a comment instead.

> Even logical splits impede readability, because they require tracking and navigation during reading.

IME, most reading of code has a specific focussed goal for which logical splitting allows not reading lots of irrelevant code you'd have to read if it was a non-abstracted mass.

I take this approach for internal divisions within the same file. For external APIs, you're operating under a completely different set of constraints. As I recall, similar advice was in the original Clean Code: context guides which principles you apply.