An overview of the science on function length
The heading is sort of misleading.<p>&gt; To put it plainly, if we have a long function and split it into smaller ones, we’re not removing a source of defects, but we would simply be switching from one to another.<p>Of course ... But when you use short functions, you try to abstract things and make these functions usable in general cases. Who thinks, that simply splitting up a long function with zero changes fixes any bugs? Hopefully very few people. The only advantage in that case would be, that one can think in the context of that smaller function about what it is doing and that might help to find a bug _and then fix it_ by changing the logic. By then we have done already more than simply splitting up the long function though.<p>Long functions usually do more than one thing to achieve a more complex thing, which requires doing multiple steps. That makes them less reusable. They become too specific in what they achieve. If ones naming skills (those are very important) are not up to the task of naming long functions precisely, then perhaps one will forget, that this long function does something very specific inside to reach its goal. It will silently have lost composability. Other developers for sure will not know, unless they read all the code. I have seen atrocious 300+ loc functions, which serve exactly one purpose and interact with so many parts of the system, that I can read them 10 times and still do not get what they do in their entirety.<p>By not using small functions, one gives away readability as well. Every function is a chance to give a name to some short program. Short functions can be looked at separately, if written well. Of course, if you modify a lot of global state in your short function then no one can help you any longer.<p>&gt; All of the studies measuring defect density found increased defect density for smaller functions. One possible explanation was suggested by [2], who proposed that the increase in errors was due to what they called “interface errors” – that is, “those that were associated with structures existing outside the module’s local environment but which the module used.” This would include errors such as calling the wrong function.<p>Well, that happens usually, when the naming is off or difficult to remember or follow. That is why naming things is an incredibly important skill. The name of a function should, if possible, give a good picture (by convention if there is any) of what the function is doing. Do not tell me, that the 100 loc function can be described in a single verb. It is most likely doing much more than one thing.<p>So in general I am not convinced by how the title and intro of the article put it. If we look at the article, the title is also actually different than here. It says &quot;Very short [...]&quot; not &quot;short&quot;.<p>They would have to limit the scope of their study a lot, to make a good point. For example:<p>(1) procedural code &#x2F; mainstream &quot;every noun is a class&quot; code &#x2F; functional code<p>(2) the kind of expertise of coding people allowed to take part (Was the code written by capable people?)<p>(3) the programming languages they look at<p>It seems that this research might be biased by what code they looked at. Some programming communities are not as well known for keeping code clean as others. They are often associated with &quot;only learned one programming language ever, never widened their horizon to a different methodology or paradigm&quot;. Those are mainly found in languages, which are very widely used and up at the top of the programming language usage lists like TIOBE. The reason is, that being at the top of the list is used by many as a justification to not needing to learn a different tool. Many people stop learning. Here I quote the article:<p>&gt; However, nowadays the vast majority of functions are under 50 lines. A quick analysis of Eclipse, a popular open source IDE, reveals it averages about 8.6 lines per method in its source code.<p>Relating to an IDE, which is mainly used for Java.<p>&gt; This shift in function sizes is perhaps partially due to changes in programming languages. In the 80s a Fortran “module” was commonly considered a function and some variables  (see eg. <a href="https:&#x2F;&#x2F;www.tutorialspoint.com&#x2F;fortran&#x2F;fortran_modules.htm" rel="nofollow">https:&#x2F;&#x2F;www.tutorialspoint.com&#x2F;fortran&#x2F;fortran_modules.htm</a>) and function was the basic building block of software, whereas nowadays most Java or C++ programmers would define “module” as a class consisting of multiple functions.<p>They do that, because for a long time their languages were so limited, that they did not have any other means of expressing a module. This also discouraged a style which does not use objects, but only functions. Add to that, that Java (and I think neither C++) does not have TCO and you have yet another reason, why Java or C++ code is not a good argument, when talking about short functions. Java got modules now, as far as I know. Not sure developers make proper use of them.<p>I would like to see the same research being done on a language like Haskell or Scheme, one language at a time.