<i>That&#x27;s an oversimplification of the research, and misleading.</i><p>OK, I concede that I simplified there, though I think you’re being a little harsh. When we’re discussing shorter vs. longer functions today, it seems fair to say we’re usually considering scales of perhaps 5 lines vs. 25 lines vs. 100 lines. I did write “longer <i>but otherwise reasonable</i>”, and by the time we’re talking about 200+ lines in a single function, I expect most of us would consider most such functions undesirable for reasons other than their length.<p><i>I wouldn&#x27;t advocate for a strictly short functions either, but the overall body of evidence definitely does _not_ suggest the opposite conclusion: the opposite conclusion would be that we should endeavour to write long functions!</i><p>Well, some of the evidence does seem to suggest that that might be a better strategy, within the bounds of common sense and other things being equal.<p>However, in reality, I don’t think other things <i>are</i> equal most of the time in programming. Personally, I find criteria like having one responsibility and clearly describing how it is met more useful for writing good functions than crude metrics like the number of lines.<p>Given that there are a lot of correlations between otherwise undesirable features and function length, we should be wary of assuming causal relationships in any case. But we surely shouldn’t be advocating the trendy very-short-functions approach as some obviously superior style when if anything the balance of evidence is against it.