5 ms·

Lets see, in the 2nd edition of code complete, section 7.4 "How Long Can a Routine Be?" has a bunch of studies listed. Lets take a look: 1. A study by Basili a

Lets see, in the 2nd edition of code complete, section 7.4 "How Long Can a Routine Be?" has a bunch of studies listed. Lets take a look: 1. A study by Basili and Perricone found that routine size was inversely correlated with errors; as the size of routines increased (up to 200 LOC), the number of errors per LOC decreased (1984). 2. Another study found that routine size was not correlated with errors, even though structural complexity and amount of data were correlated with errors (Shen et al. 1985) 3. A 1986 study found that small routines (32 LOC or fewer) were not correlated with lower cost or fault rate (Card, Church, and Agresti 1986; Card and Glass 1990). The evidence suggested that larger routines (65 LOC or more) were cheaper to develop per LOC. 4. An empirical study of 450 routines found that small routines (those with fewer than 143 source statements, including comments) had 23% more errors per LOC than larger routines (Selby and Basili 1991). 5. A study of upper-level computer-science students found that students' comprehension of a program that was super-modularized into routines about 10 lines long was no better than their comprehension of a program that had no routines at all (Conte, Dunsmore, and Shen 1986). When the program was broken into routines of moderate length (about 25 lines), however, students scored 65% better on a test of comprehension. 6. A recent [sic!] study found that code needed to be changed least when routines averaged 100 to 150 LOC (Lind and Vairavan 1989). 7. In a study of the code for IBM's OS/360 operating system and other systems, the most error-prone routines were those that were larger than 500 LOC. Beyond 500 lines, the error rate tended to be proportional to the size of the routine (Jones 1986a). 8. An empirical study of a 148 KLOC program found that routines with fewer than 143 source statements were 2.4 times less expensive to fix than larger routines (Selby and Basili 1991). The 25 lines is just one of the studies, related to students of CS in particular. In general, it seems like the data indicates that somewhere between 100 and 200 is optimal for minimum errors per line, lowest cost to modify, less need to modify, and overall undesirability. So the "short, 5-10 line functions" seems to be not only entirely unsupported by empirical data, but actually harmful in general.

jasonlotito 13y ago
Thanks for that. Though, LOC seems to fall into the "What is a line of code trap." Study 2 also supports complexity with errors, not size (small or large). I hadn't realized how old these studies were, however. For some reason, I thought they were from the 90's. I'd be wary about relying on, what is, frankly outdated assumptions.
- gruseom 13y ago
  I'd be wary about relying on, what is, frankly outdated assumptions. You'd be wary, and so you'd replace these studies with what exactly? Which of their assumptions are outdated? Let's not fall into the trap of thinking that programmers before us didn't understand as much. As far as I can tell, the issues were much the same. A greater problem with older studies is that their sample sizes were mostly small and their experiments never replicated.
  - mattmanser 13y ago
    They really didn't. I'm going to be frank, in the 80s, programmers sucked compared to today's programmers. If you took an 80s programmer and time shifted him to today, he'd look like he had no experience and really struggle until he'd spent a lot of time learning new stuff. You've grown up with software engineering in the last 10 years. Have you honestly not seen the sea change in that time? Be it programming languages that have shifted dramatically from the original OO in Java/C# 1.0, javascript inspiring massive changes in those languages with anonymous types, closures, etc., with unit testing, TDD. There's so much that's changed, so, so much I can't even think of half of it. I said it below, who today passes ByRef? Or uses a global variable? 10 years ago that was common. Just 10 years ago! The field is moving so amazingly rapidly! And one of the real things I've seen, something you can't describe unless you've got experience, which I've no doubt you have, is that methods now actually do what they say they do. They didn't used to. They used to do other things, and touch global vars, and get passed in variables to muck around with. And on top of that, people now seem to actually understand OO. Not just blindly recanting what polymorphic means, they can actually split up and create objects sensibly. They really couldn't do it very well 10 years ago. No-one really understood it, it sounded like a good idea but only a tiny percentage actually understood what it really meant. And yet you think studies done back then, using techniques that would get people fired today, are worth referencing? LOOK at the dates in the parent post. 1986? No Java, no Javascript, no Python, no Ruby, no C#. But COBOL had just released an update! You'd better watch out for those GOTOs! I honestly am perplexed that you can even start to think those studies are still relevant today.
    - 13y ago

jasonlotito 13y ago

Thanks for that. Though, LOC seems to fall into the "What is a line of code trap." Study 2 also supports complexity with errors, not size (small or large). I hadn't realized how old these studies were, however. For some reason, I thought they were from the 90's. I'd be wary about relying on, what is, frankly outdated assumptions.

gruseom 13y ago
I'd be wary about relying on, what is, frankly outdated assumptions. You'd be wary, and so you'd replace these studies with what exactly? Which of their assumptions are outdated? Let's not fall into the trap of thinking that programmers before us didn't understand as much. As far as I can tell, the issues were much the same. A greater problem with older studies is that their sample sizes were mostly small and their experiments never replicated.
- mattmanser 13y ago
  They really didn't. I'm going to be frank, in the 80s, programmers sucked compared to today's programmers. If you took an 80s programmer and time shifted him to today, he'd look like he had no experience and really struggle until he'd spent a lot of time learning new stuff. You've grown up with software engineering in the last 10 years. Have you honestly not seen the sea change in that time? Be it programming languages that have shifted dramatically from the original OO in Java/C# 1.0, javascript inspiring massive changes in those languages with anonymous types, closures, etc., with unit testing, TDD. There's so much that's changed, so, so much I can't even think of half of it. I said it below, who today passes ByRef? Or uses a global variable? 10 years ago that was common. Just 10 years ago! The field is moving so amazingly rapidly! And one of the real things I've seen, something you can't describe unless you've got experience, which I've no doubt you have, is that methods now actually do what they say they do. They didn't used to. They used to do other things, and touch global vars, and get passed in variables to muck around with. And on top of that, people now seem to actually understand OO. Not just blindly recanting what polymorphic means, they can actually split up and create objects sensibly. They really couldn't do it very well 10 years ago. No-one really understood it, it sounded like a good idea but only a tiny percentage actually understood what it really meant. And yet you think studies done back then, using techniques that would get people fired today, are worth referencing? LOOK at the dates in the parent post. 1986? No Java, no Javascript, no Python, no Ruby, no C#. But COBOL had just released an update! You'd better watch out for those GOTOs! I honestly am perplexed that you can even start to think those studies are still relevant today.
  - 13y ago