Hi there... We've all read excessively long methods or functions, where your eyes end up bleeding when you reach the return statement. We've also seen those one-liner functions that seem pointless...
I just wanted to ask: which do you think is the best average length for a function/method? Having into account that every language has it's own ways, you could specify which one you're referring to in your answer. Thanks!
Shorter methods with a multitude of other method calls just to reduce the code in one particular method does not necessarily signify a "better" method.
What to concern yourself with is not the length, but the complexity, readability, usability, and scalability of the method, and whether the code can be refactored into a simpler, easier to read, less complex version.
As Abraham Lincoln said when asked how long a man's leg's should be, "long enough the reach the ground".
Every function/method will be different.
There's no point discussing "average function length". You have to use the rule of the thumb. Function/method has to have a very precise functionality, that should be represented by its name. If you can't define "what does it do" in its name, you should split it. But it length may vary, as some very definite tasks require quite substantial amount of code.
And as you have said, looking at some functions makes your eyes bleed. If they bleed, something is wrong with the function ;)
For me it is very hard if a function is longer then a printed page. I also dislike wrapping line in a printout. Does this make me old fashioned or do I give my age away - printing code?
I would also say that if the name of a called function within my code is not telling me what the function does, it often is more cumbersome to jump through several functions to find out what is done. That reminds me of the good ol' COBOL days, where we printed code, spread it out in the hallway, and four guys were trying to follow all the GOTOs. (Now you definitively know that I've been around a while.)
So it is a ballance between length and good naming conventions.
Trying to define an average method length just for the sake of it is like stating that more lines of code equals better productivity.
Method length is a meaningless number. You measure the quality of a method by its specificity, efficiency, robustness, and readability; not how many lines there are. The number of lines becomes even more meaningless when you consider different coding styles - some people just like to have a lot of whitespace.
If you really really want a guideline, just automatically assume that any method that's longer than one page scroll or two (depending on your resolution) is probably too long.
A function should never be longer than a screenful.
Functions should be as long as your attention span, so that it is possible to keep the entire meaning of it in your head. The aim should be to express the solution of a problem as clearly as possible.
Having a rule of thumb on the maximum length is a good idea because it gives you a good indication on when you might not have achieved enough clarity. In my opinion, you can be fairly certain that anything longer than a screenful is probably not clear enough, so I use that as a rule of thumb, but I strive to make functions as short and succint as possible.
One line functions are perfectly acceptable if they make the code clearer, i.e. if the code in it doesn't already obviously read what the function does.
Encapsulating complexity is one of the most important roles of functions. It tells the reader that this piece of code can have nothing to do with that piece of code, except through parameter/result values. Complexity is also the reason why side effects should generally be avoided.
Naturally, small functions are easier to read, but if there is no complexity, e.g. setting 200 options in a configuration object, then by all means, have a function with 200 lines.
Splitting functions with low complexity may increase readability for that function but it will also increase global complexity, a little.
It's not so much the length that makes good method implementations. Length ist one aspect among others in judging the quality of a method implementation:
Any other quality criteria that I missed?
My rule is: It should be obvious by brief inspection (say, 30 seconds or less) that the function's name corresponds to its implementation, assuming that any functions it uses have implementations that correspond to their names.
Practically, this means that my functions are pretty short. Some of them are simple definitions. As a pathological example:
int AdditiveInverse(int x) { return Negate(x); }
If AdditiveInverse and Negate are distinct concepts in my head, and just happen to coincide in the real world. There's nothing wrong with a teeny function if it introduces a new concept.
I've found this rule of thumb is easier to pull off with a pretty high-level programming style. Memory management, separate index passing, etc. hinder the feasibility of this. I find functional languages to be especially amenable to this style: it's an unbreakable guideline to me when I'm writing Haskell, and a loose heuristic when I'm writing C#.
I think the guys of Object Mentor have thought about this issue for a while. They have a similar question posted some years ago: http://blog.objectmentor.com/articles/2007/10/29/how-big-should-a-function-be
An you can have a look at this great talk, Clean Code III: Functions, http://www.viddler.com/explore/oredev/videos/15/