It's a lot more than these two things, in fact I think these two things are not as important as the main benefit of smaller functions, which is making code that is easy to understand at a glance. Good naming with proper separation of logic into small pieces can make even c++ read almost like prose. It's hard to find, but when you see it, it always blows me over.
Re:Function Length
by mannykannot on Sunday December 04, 2016 @12:52PM
(#13100866)
While I do not disagree with Fowler's criterion as being one of several to consider, The ability of function (and identifier) naming to make code "easy to understand at a glance" is frequently overstated, including in this article. Once code reaches a size where it is moderately complicated, the reasons for some action being done in a particular way are not necessarily locally obvious (or obvious at all.) One common reason for this is that things are being done in a particular way to conform to a contract that is relied upon in multiple, disparate parts of the program (and any reasonably large program does have such contracts, even if it was not produced by an explicitly design-by-contract methodology.)
For a flavor of how this works, read the article [1] below, in response to Tom Cargill's classic article 'Exception Handling: A False Sense of Security'. Even though the code example here is small enough to be understood in one go, I doubt that the reasons for it being the way it is are immediately obvious to most programmers, unless they have been primed by exposure to the issue before (note that the first answer given was not entirely correct.)
(A) Simplified flows of data in/out rather than a huge complicated input and a huge complicated output complicated parameter/return data flow
(B) Reusability, since bigger functions are more likely to be "custom fitted" to a particular purpose.
If your huge function has very simple parameters/returns, and no subparts you want to reuse, then odds are there's no need to break it apart.