Taller Than Me

Printed on fan-fold paper, no function should be longer than you are tall!

This was an old principle, but humorous enough to include.

My personal experience is that I can't even read a function that runs over 4 pages (let alone six linear feet), because I'm unable to maintain enough context in my head to understand that much code. I have the same problem if indentation gets too deep. Maybe I'm just "challenged", but I've also noted that most good OO programmers write very short methods most of the time.

Every time I've ever written methods that were too long, I've been stymied in trying to refactor them later and also in trying to maintain them. It's best to just never get into that situation.

This is often a symptom of violating the OneResponsibilityRule.

I like methods that fit in their entirety in one screen (without reducing the font size!). This is typically about 40 lines.

Most people would consider ten lines to be the practical limit, and strive for even fewer than that. Forty is way, way too big for a single method, except perhaps for some sort of huge case statement. See ShortMethods.

I think you give way too much credit to "most people". My experience is that quite a few think nothing of writing 500-line procedures. It needs to be made illegal. -- AdrianLloydFlanagan

What about a hand-optimized FFT, or any other sufficiently complex numerical routine? --AndrewQueisser

Well, the FFTW implementation actually compiles to optimized C source, from OCaml code. Why? Because FFT has a lot of optimization cases (real valued vs. complex valued, etc) that is ridiculous to implement yourself. So, I think that to hand-optimize numerical methods isn't a valid excuse for writing functions taller than yourself! --Anonymous

The trick is, you need to consider the hand-optimized code to actually be hand-compiled code. This gives you the freedom to keep the 'source' code around.

Arbitrary rules such as this are part of the reason why the average (mediocre) programmer generates such crap. If y'all insist on trying to reduce programming to the memorization of simple rules of thumb, then pick good ones. A much better pair of memes to proliferate are that a function or procedure or method should have conceptual unity (it should do one thing well) and that repetition should be reduced where sensible by factoring out common steps. Those alone should naturally lead to rather smallish functions wherever smallish functions are appropriate without encouraging senseless arbitrary division.

I'd rather be stuck reading a single long sequence of poor code than jump back and forth around a class definition reading something that was broken up merely to satisfy some arbitrary sense of scale. At least nobody will try to specialize part of the long, poor method in a derived class, as they'll be encouraged to try if that same crappy code were split up senselessly into a succession of smaller methods.

In a similar vein, I've seen even smart people break up a class because "it has too many methods" despite the fact that there were no logical lines along which to split it. Under the force of these arbitrary ideas, even the bright but inexperienced folks can be lead astray. Our field desperately needs sensitivity and precision, not folksayings. -- AnonymousDonor

True but perhaps not as useful as TallerThanMe. The advantage of simple rules like method size is that it's really easy to tell when you've broken them. It's possible to look at a 150 line method and say "Oh, it has conceptual unity, no refactoring needed here." But if the rule says the method is too long, you start looking for how to break it up before you look at whether to break it up. Often you'll find logical split points that aren't obvious at first glance.

In a sense, method length is more of a trigger than a hard-and-fast-rule. AllRulesAreMeantToBeBroken? (see ShuHaRi?). But it's one of those rules where you should think hard and fast before breaking it, and only do so if there really isn't an alternative. -- JonathanTang

Some are what I call "yellow alert rules". They are signals to be watchful when encountered. Long function/methods are indeed something to keep an eye on, but I have seen some long ones that were perfectly acceptable. It is all a matter of good judgement.

Not only that, but hard and fast rules tend to come from people who have really focused experience, and aren't even aware that there are problem domains where rules like this one must be broken, that it's not even a matter of choice. -- DougMerritt

One of the things that I always do is to start line-by-line comments on column 61. When code starts to creep too far into that margin, that is one of the indicators that it may be time to break that code out to another function. IME, it serves to be a pretty decent way to ensure that code does not get too out of hand. You do not have to comment as much as I do, but you can still have the "hard deck" of some column. (I only mention this in response to the point of indentation getting too deep) -- JamesTwine

See LongMethodSmell