|
|
|
|
|
|
by nimnio
3797 days ago
|
|
|
"More significantly in this particular case, various studies over the years have not supported the claim that short functions have better error rates, nor that longer but otherwise reasonable functions have higher error rates; if anything, the overall body of evidence seems to suggest the opposite conclusion." That's an oversimplification of the research, and misleading. After citing five studies in Code Complete (including the one that shows an inverse correlation between errors and function size), McConnell summarizes as follows: "That said, if you want to write routines longer than about 200 lines, be careful. None of the studies that reported decreased cost, decreased error rates, or both with larger
routines distinguished among sizes larger than 200 lines, and you’re bound to run into an upper limit of understandability as you pass 200 lines of code." I wouldn'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! Anyhow, nitpicking aside, thanks for providing a quick review of this book. I'm going to skip it based on your comments. |
|
|
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 but otherwise reasonable”, 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.
I wouldn'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!
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.
However, in reality, I don’t think other things are 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.
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.