Is there an optimal number of lines of code per function? [closed]

Question

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?

Answer 1

Instead of number of lines, the criteria I would use is that each function should do only one thing and does it well.

Answer 2

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.

Answer 3

There is none.

Screens are getting bigger, font sizes smaller. Rules of thumb don't work so well when people have different sized thumbs.

Be concise. If your function does multiple things it's probably a good idea to break it up into smaller ones.

Answer 4

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.)

Answer 5

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.

Answer 6

The answer is of course 42.

Important to note: No funcion may ever violate the SRP, or you have to face the spanisch inquisition.

A few hints how to reduce the ammount of lines:

• Are there comments marking individual sections? Those sections should be functions.
• Are there if-else chains or switch statements outside of a factory/builder? Your design may need some better design patterns to help you split responsibilities.
• Are your functions easy to test? Make your functions easy to test, they will fall apart.
• Is it complex and just no land in sigth (1000 line monsters)? Do scrap refactoring - that is refactor and don't save it in the hope to get educated about the codes responsibilities.

Answer 7

Here are some clues:

• If you are having trouble writing the comment explaining the purpose and usage of the function, it is too long.

• If you are tempted to write a comment explaining the activity of a section of code in the function, then the function is too long.

• If you are pasting code from another function, then they are both too long (extract that code as a separate function).

• If you need a coding convention to separate class data members from local variables, then the function is too long, and the class has too many members.

• If you need to take notes while reading a function, it is too long.

Having 'tonnes' of functions, each only one or two lines long, is not necessarily a bad thing. I found that those little functions were reused much more than I initially expected.