3 ms·

I'm unconvinced. Two notes - first, the experimental evidence seems to involve taking people unfamiliar with the codebase and asking them to debug or investiga

I'm unconvinced. Two notes - first, the experimental evidence seems to involve taking people unfamiliar with the codebase and asking them to debug or investigate code with either long or short functions. I can certainly conceive of it being easier to learn and debug a single long function than multiple smaller ones if one is unfamiliar with the codebase. I'd expect that effect to go away once one is asked to debug the same code again. Second, the article asserts more bugs are found in shorter functions. However, this is only taking lines of code into account, not functional complexity. As code lives, bugs are found and corrected; often those bugs are to do with unforeseen runtime circumstances. Joel Spolsky covered this memorably a couple decades ago [1]. Again, taken as a static snapshot, I am not surprised that short code correlates with bugs, but I don't think that tells us any meaningful information about how to code. A codebase is not a static entity. As pointed out by several people already, the point of short functions is abstraction and comprehensibility - we want one and only one place to talk about reading a file, one and only one place to talk about handling a particular message type. Similarly, we want to know when we look at a function that it does one and only one thing, and we want to know when we look at our code that what it says it's doing is what it's actually doing. I think this is one of those studies similar to the "judges sentence harsher before lunch"[2] study - the type of effect discussed fails under any reasonable comparison to commonly-experienced reality. Consider your own personal experience working in codebases and how this article aligns with that - phenomenological reporting can indeed be suspect, but when it contrasts starkly with experimental results it often indicates poor study design. [1] https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... [2] http://nautil.us/blog/impossibly-hungry-judges http://nautil.us/blog/impossibly-hungry-judges (I hope I can use this level of motivated reasoning to critique the next study I agree with, too.)

eesmith 6y ago
Several of the papers referenced, at least, use empirical evidence not based on the experimental procedure you described. Eg https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-2005-149.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/... and https://www.inf.usi.ch/faculty/lanza/Downloads/DAmb2010c.pdf https://www.inf.usi.ch/faculty/lanza/Downloads/DAmb2010c.pdf . I think the author is not saying "more bugs are found in shorter functions" but that more defects are found in software modules with shorter functions. Hypothesized reasons for this include ""interface errors"" and ""it’s plausible that creating functions will always carry some [cognitive] overhead in itself"". Even then, the only firm conclusion is for very small functions, at most a few lines long. Are those the same sorts of short functions you mean? You write: "A codebase is not a static entity." And that's true. Which is why the cited paper https://www.inf.usi.ch/faculty/lanza/Downloads/DAmb2010c.pdf https://www.inf.usi.ch/faculty/lanza/Downloads/DAmb2010c.pdf (for example) tracks repository changes for several open-source projects for several years, and correlates them with reported defects. That was used in the essay, eg, ""this is likely because we consider all bugs over the ~4 year period"". My own history is that working with code bases which follow the 'functions should be only a few lines long' approach drive me batty because I can't remember all those function names which are only used once, and because many of those code bases treat instance methods as pseudo-global variables, and modify them will-nilly. So yes, the conclusions given here agree with my personal experience, so suggest that it is a good summary of research which was reasonably well-defined. Which is a rather different conclusion that yours, yes?
legulere 6y ago
> the point of short functions is abstraction and comprehensibility If you have clean code style short functions you get nothing of that. There you split functions into more functions just for the sake of it. You end up with function names that describe the code worse than how the code describes itself, similar to comments beginner programmers make. Why is a comment "Increments i by one" for i++ not ok, while a function "incrementIByOne" is supposed to be good style? Even if you don't make functions clean code-style ridiculous short, abstractions still come with a cost. You have to do weigh costs and benefits each time.
- Someone 6y ago
  “Why is a comment "Increments i by one" for i++ not ok, while a function "incrementIByOne" is supposed to be good style?” It isn’t, but nextOrderNumber could be, especially if it is used in multiple places. That function could easily evolve into _doing_ “increment i by one, atomically”, “generate a random UUID”, “get a new unique ID from the database”, etc.

eesmith 6y ago

Several of the papers referenced, at least, use empirical evidence not based on the experimental procedure you described. Eg https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-2005-149.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/... and https://www.inf.usi.ch/faculty/lanza/Downloads/DAmb2010c.pdf https://www.inf.usi.ch/faculty/lanza/Downloads/DAmb2010c.pdf . I think the author is not saying "more bugs are found in shorter functions" but that more defects are found in software modules with shorter functions. Hypothesized reasons for this include ""interface errors"" and ""it’s plausible that creating functions will always carry some [cognitive] overhead in itself"". Even then, the only firm conclusion is for very small functions, at most a few lines long. Are those the same sorts of short functions you mean? You write: "A codebase is not a static entity." And that's true. Which is why the cited paper https://www.inf.usi.ch/faculty/lanza/Downloads/DAmb2010c.pdf https://www.inf.usi.ch/faculty/lanza/Downloads/DAmb2010c.pdf (for example) tracks repository changes for several open-source projects for several years, and correlates them with reported defects. That was used in the essay, eg, ""this is likely because we consider all bugs over the ~4 year period"". My own history is that working with code bases which follow the 'functions should be only a few lines long' approach drive me batty because I can't remember all those function names which are only used once, and because many of those code bases treat instance methods as pseudo-global variables, and modify them will-nilly. So yes, the conclusions given here agree with my personal experience, so suggest that it is a good summary of research which was reasonably well-defined. Which is a rather different conclusion that yours, yes?

legulere 6y ago

> the point of short functions is abstraction and comprehensibility If you have clean code style short functions you get nothing of that. There you split functions into more functions just for the sake of it. You end up with function names that describe the code worse than how the code describes itself, similar to comments beginner programmers make. Why is a comment "Increments i by one" for i++ not ok, while a function "incrementIByOne" is supposed to be good style? Even if you don't make functions clean code-style ridiculous short, abstractions still come with a cost. You have to do weigh costs and benefits each time.

Someone 6y ago
“Why is a comment "Increments i by one" for i++ not ok, while a function "incrementIByOne" is supposed to be good style?” It isn’t, but nextOrderNumber could be, especially if it is used in multiple places. That function could easily evolve into _doing_ “increment i by one, atomically”, “generate a random UUID”, “get a new unique ID from the database”, etc.