I hope most people are cringing at the unmistakable tremor in the force these words invoke (at least for me). A colleague of mine, after a code review, tried to argue that sometimes larger methods are better than smaller focused methods and used Steve McConnell's seminal work Code Complete as evidence to support this claim - specifically section 5.5 “"How Long Can a Routine Be?”.
The studies sighted in this section are at the very least likely out of date. In an effort not to be dismissive, I actually found and read one of the studies. It correlates smaller methods with higher incidents of bugs. Here is an excerpt from the study and the explanation as to why:
“An unexpected trend was observed: Table VII implies that there is a higher error rate in smaller sized modules. Since only the executable lines of code were considered, the larger
modules were not COMMON data files. Also the larger
modules will be shown to be more complex than
smaller modules in the next section. Then how could
this type of result occur?
The most plausible explanation seems to be that the
large number of interface errors spread equally across
all modules is causing a larger number of errors per
1000 executable statements for smaller modules. Some
tentative explanations for this behavior are that: the
majority of the modules examined were small,
causing a biased result; larger modules were coded
with more care than smaller modules because of their
size; and errors in smaller modules were more apparent.
There may still be numerous undetected errors
present within the larger modules since all the "paths"
within the larger modules may not have been fully
exercised.”
So the results support the premise, but only because the data was flawed.
If you are going to make an argument, articulate it using your own experience and the wisdom of your knowledge. Then you are not just regurgitating something you read in a book or online, but rather demonstrating that you have tested and internalized that information and can make an educated decision on whether it is an approach worth taking and why.
Posts
Intuitively, the "tentative explanation" from the study would seem logical: Smaller methods/modules increase interface area. They spread the logic out, making it more abstract and harder to internalize.
ReplyDeleteSo maybe there's a tradeoff - these things balance the (clear) advantages of keeping methods and modules small - which advantages have been hammered into our heads ad infinitum.
As in everything, there is a balance point somewhere. Surely for code that point is on the small end of the scale, but it makes sense that there's some extreme past which smaller is worse.
I agree that there is a balance, and there are times when a one line method or a class with a single method are appropriate.
ReplyDeleteAll of it comes down to four factors:
maintainability, testability, effective communication (which I will write about in greater detail in another post), and our ubiquitous friend, context.
I prefer methods that are doing one thing. If they are over 50 lines (white space included) then I pause to consider refactoring.
ReplyDelete