Posted by: drew | March 14, 2006

The “20 Lines” Rule

Ozone has a post about coding standards which includes a rule that states: “No method body shall be longer than 20 lines”

The reasoning is stated as:

You see, 20 lines of code is more than enough to express an idea concisely and it is also about the right amount of information the eye and the brain can scan and comprehend without having to do too much double-takes — not that I have data to back this up, but 20 lines happens to snugly fit in most screens/windows used while coding, thus reading the code does not require interrupting the train of thought by scrolling. If the only impact of this rule was enhanced readability, you would accuse me of false advertisement.

Most benefits from this rule actually cascades from the side effects of breaking down a large method in a set of smaller methods. The most dramatic effect is the reduction of the cyclomatic complexity of the code. Here comes the esoteric concept! Crudely, the cyclomatic complexity of a piece of code is a measure of the number of possible execution paths through it. Less execution paths means less execution paths to test. Bingo! We have just simplified our unit tests. The emergence of smaller methods improves abstraction and reusability. Indeed, very frequently these methods can be invoked in other parts of the code base, thus reducing redundant code.

Interesting. To to sum up, the benefits are readability and encouraging breaking down problems into smaller parts.
Below the fold I’ll give my impressions…

This “standard” makes a lot of sense in a “Thanks, Captain Obvious!” sort of way.

Having said that, I can’t say I’ve heard it stated or quantified that way. Any experienced programmer should know that avoiding bloated methods is a good thing, both for algorithm development as well as readability.

This idea of a optimum number of “things” for the human brain to process is widely utilized in business and our every day lives. Why do you think phone numbers in the US are structured the way they are in the US? The length and structure is optimal for the average human memory. Further, in the business world, organizational management maintains that managers have only so many things “on their plate”, whether it be projects, employees, etc. Without looking it up, I think the number 7 is widely considered a “magic #” when it comes to the average human memory.

I’m not arguing that 20 is the optimal number of lines in a method, but hey, it’s a start. The point is to put hard limits on your function body and when you butt up against that, carefully consider whether your method is optimized and organized as it should be. I can see some complex mathematical functions needing more than 20 lines, but at least if it goes more than that, you’ve thought about it and are sure that > 20 is best.

Having said all this, I’ve not put this to the test yet. I look forward to testing this “standard” out.

One important wrinkle that arose in the comments below this article was that comments would likely blow this rule out of the water. One fella said that if you write good code, you don’t even need comments…

I disagree with this opinion. First of all, “good code” is somewhat subjective. Good programmers write bad code and vica versa. Sometimes the project schedule is FUBARed, or your dog gets hit by a car and you aren’t up to writing “good code”. That doesn’t mean that future coders should have to suffer, does it? To me, this attitude is extremely self-centered and arrogant. Guess that guy’s s**t doesn’t stink, eh?

Not only do good comments describe the intent behind the code, they also provide an invaluable resource to programmers doing maintainence work. Perhaps it’s because I come from a writing and English background, but there are few things in development that bug me more than crappy or non-existant comments.

My approach in trying out the “20 line” rule will be to do my best to write clear and concise comments as usual, but try and limit the actual code to 20 lines. I guess I could always put my comments in line with real code, but that’s not always my style.

Anyway, it is an interesting article that got me thinking a bit. That’s always good.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s


%d bloggers like this: