Long Functions

If one is doing procedural-style code, what are the rules of thumb you use to divide up functions? Some suggestions:

Long functions are not inherently bad. Long functions are not a problem if well-designed and simple. Large length is only a smell, not necessarily bad practice, but it is a smell worth taking a close look at.

That doesn't pass the platitude test. Nobody would ever say "Long functions are a problem even if well-designed and simple." Somebody following your guideline is always entitled to write functions of any length, telling themselves "But this one is well-designed and simple".

True, but that criticism is true of all CodeSmells, yet they do exist. The difference between a smell and an outright bad practice is precisely that there is no absolute hard and fast rule; judgment must be used. -- AnonymousDonor

Meyer's platitude test is insightful, but platitudes are sometimes useful. When you state a platitude ("X", say) the information you're really communicating isn't that X is true, but that X is worth paying attention to. That can be valuable information even if X is both obvious and uncontroversial. -- GarethMcCaughan

My advice is to ignore the length of the function. Begin to refactor the code into an object oriented style by combining code and data declarations. This will improve the modularity of the code, reduce coupling, and increase cohesion. After a while, the long functions will just melt away. Don't refactor code just to reduce the length of a function. Refactor the code to improve its structure and let function length take care of itself.

[My advice is to pay attention to the length of the function. Try to imagine that you are seeing the function for the first time. Is there a sequence of statements that could be summarized with a single comment? If so, ExtractMethod on those statements. Try to make the function as painfully obvious to a naive reader as possible. -- EricHodges]

But one major lesson I have learned over the years is that what bothers person X may not bother person Y, and visa versa. I can only speak for myself and guess of others. If there is a clean visual pattern to the code (from my perspective) and it does not majorly violate OnceAndOnlyOnce, I usually have little reason to complain about a longer named unit.

This was a long and heated discussion, but some people gathered empirical data . This is from CodeComplete 2nd edition:

Very interesting. Some of the better code I have written has had long functions (100 - 200 lines) with say twenty local variables. The functions often did this, followed by that, followed by the third thing, wrapped in a loop over the whole thing. Since I used some global variables (I refuse to allocate 16k buffers on the stack), and these functions were one level away from main, ExtractMethod wasn't that much work, and I did so whenever I saw the same code appearing twice.

See also LongFunctionsDiscussion, RefactoringMercilesslyHidesTheForest; also TryLikePages
