An overview of the science on function length
I think that this result is rather intuitive, even in the common paradigm of &#x27;a function should do one thing and have a good name that describes that thing&#x27;.<p>Essentially, the idea that code is easier to understand with small, well-named, cohesive functions relies on the functions being bug-free themselves, and on the relevant behavioral details being perfectly caught in the name and types.<p>However, if small functions have bugs, it is pretty intuitive that it takes more time to explore a call graph than a linear code listing to find that bug.<p>Furthermore, when chaining many small functions to achieve a more complex functionality, bugs can more easily slip in the chain itself. For example, a function may modify a list you pass in and also return it, when your chain assumed it would return a copy. A sort function may be unstable when the calling code assumed it was stable. A function may move to another thread when the calling code assumes that locking is unnecessary.<p>All of these would be easier to catch if the code were inline, instead of abstracted behind a function signature. Of course, this has to balance somehow with not rewriting sorting procedures in every function of your code base.<p>I think that the answer probably lies with some idea of separating library code and application code. Library code should be composed of many small functions, well documented and well unit-tested. Application programmers should all be familiar with the library and its semantics. In contrast, application code should probably favor larger functions and avoid ad-hoc abstractions. If there is a small piece of functionality that seems re-usable, it should usually not be moved to a separate function, but to a separate library.