What's the Right Size, Really?
Depends on the language you use, but in general (and for my personal taste):
- Ideally, less than 25 lines.
- Acceptably, less than 35 lines.
If it's more, then it's something I need to come back to later and rework.
But realistically, any size it needs to be when you need to deliver something and that it makes more sense on the moment to spit them out like that, makes it even easier sometimes for someone to review before shipping. (but still get back to it later).
(Recently my team ran a program on our codebase: we found class with 197 methods and another with only 3 methods but one of them was 600 lines. Cute game: what's the worse of the 2 evils?)
Now for a more zen answer... In general it's considered a good practice (TM) to quote one or two great men, so here goes:
Everything should be made as simple as possible, but not simpler. - A. Einstein
Perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away. - A. de Saint Exupéry
Addendum on Comment Styles
As an addendum to this, your functions should have clear names explaining their intent. Regarding comments, I usually don't comment inside a function:
- comments say "why?",
- code says "how?".
A comment block at the top of each function (that requires explanation) is enough. If your function is small and function names are explicit enough, then you should just need to say what you want to achieve and why. I use inline comments only for fields in some languages or on block starts for functions that break that 25-35 line rules if the intent is unclear. I use a block comment inside the code when an exceptional situations occurs (a catch block where you don't need or want to do anything should have a comment saying why, for instance).
For more, please read my answer on Style and recommendations of commenting code
