Functions are not only used to minimize duplication of code - they are also used to split up a long function into smaller ones to increase readability, as well as making the code self-commenting. Yet this gain is not directly inversely proportional to the number of LOCs per function or method; otherwise we would have tonnes of functions, all of which only contains a single line or two of code.

This lead me to wonder: Does there exist an optimal number of LOCs per function? If so, what is it, and does it deviate between languages?

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
If this question can be reworded to fit the rules in the help center, please edit the question.

The number almost certainly varies by language: I would be surprised to see a 6-line Prolog clause, while being perfectly OK with a 20 line Delphi method. My answer below's for Smalltalk, which uses the environment to encourage short methods.
–
Frank SheararOct 5 '10 at 6:12

7 Answers
7

An old thumb rule is that a function should be entirely visible on screen, without the need of scrolling.

The basic idea is that, if you can't look at the whole function at a time, the function is over complex, and you should split it in more basic pieces.

While this rule is very practical and useful, the formal rule is that you should keep only a single logical step in a function. A function does just an elementary job, if you can divide the job in more elementary pieces, the function has to be split.

Maybe I was a bit too subtle but my intent was to imply that there is no valid reason to down vote your answer. Whoever did the deed had some random personal reason to do so. They may simply think Josh is a horrible name.
–
ChaosPandionOct 4 '10 at 21:25

Yes, if we have a unit of work I don't want to have to move between 50 functions to get the jist of what is happening. If you break out your functions appropriately using this metric they should almost naturally be reasonable in size.
–
ChaosPandionOct 4 '10 at 20:53

2

@ChaosPandion: but your unit of work may be probably expressed as a sequence of more elementary steps. If you are reviewing the function, you will review the sequence of steps, not the code of each single step.
–
LorenzoOct 4 '10 at 21:14

2

@Lorenzo - If that is the case each step becomes the unit of work. The parent function becomes a high level overview of the units of work.
–
ChaosPandionOct 4 '10 at 21:26

1

Yes, this is very true indeed. Hm, let me rephrase the question then: Is there an optimal number of LOCs for functions which does only one thing, and does it well?
–
gablinOct 5 '10 at 5:01

@gablin, hard to say and also LOCs is language dependent, but if you adhere to this principle, usually you end up within a reasonably range, say 1~50.
–
grokusOct 5 '10 at 14:52

Smalltalk has a slightly unusual way of reducing the size of methods. When you write code, you write it in a widget called a Browser. A Browser has two main parts, divided horizontally. Your code goes in the bottom half.

By default, a Browser's not very big. You can fit 5 or 6 lines in before you'll need to start scrolling. Scrolling, of course, is slightly irritating.

So in Smalltalk the environment "encourages" you to write short methods, of at most around 6 lines in length. (That's usually plenty; Smalltalk is a pretty terse language.)

The ideal number of lines of code in a method is variable. Basically, you only want to write just enough code to do what needs to be done within the context of the function's definition.
I think of this as a kind of Single Responsibility Principle, only applied to a method instead of a class.

Where a method has a lot of logic, and a number of steps to complete, then it makes sense to break the method up into several discrete steps. Each of these steps would be extracted into new methods as required.

"otherwise we would have tonnes of functions, all of which only contains a single line or two of code."

The less each method does, the more easily defined it is, and the simpler to understand and manage. There is nothing wrong with having hundreds of methods if you need them. Also, in keeping with the SRP I mentioned earlier, it becomes easier to extract new classes when the methods have been teased apart into smaller and more manageable pieces.