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

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?

• See Code Complete Vol 2 by Mitch McConnell Chapter 7 Section 4 for a good time. Oct 4, 2010 at 21:11
• @Peter - I think you mean "Steve McConnell" Oct 4, 2010 at 22:40
• Yeah, funny I'd write that while looking at the book.... Wasnt Mitch McConnell Pres. Bush's chief of staff? Oct 5, 2010 at 3:35
• 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. Oct 5, 2010 at 6:12
• @Peter Turner: Hm... S1 through S15 and I1 through I11. Sounds like he's confusing temporary variables with registers. ^^ Oct 6, 2010 at 14:55

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

• 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. Oct 4, 2010 at 20:53
• @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. Oct 4, 2010 at 21:14
• @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. Oct 4, 2010 at 21:26
• 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? Oct 5, 2010 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. Oct 5, 2010 at 14:52

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.

• This metric becomes progressively more useless as average monitor size/resolution increases. Oct 4, 2010 at 20:40
• Our programming prof just said this example the other night :) Oct 4, 2010 at 20:41
• @Anna: well, my monitor is high res but also the number of toolbars/palettes/panel has increased. And then, now I can use 14 pt pitch font! :) Oct 4, 2010 at 20:43
• The 24 x 80 size of a terminal doesn't tend to change. Oct 4, 2010 at 21:31
• nonsense, the point of the rule is "can you see it all without scrolling". With a big monitor you can have more in your function without violating this rule, it doesn't mean big monitors are only allowed to view small functions (though with all the toolbars and property windows your IDE has, this probably still holds true :-) ) Feb 16, 2012 at 23:31

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.

• Least you could do is tell my why you think my answer isn't useful. Oct 4, 2010 at 20:56
• I think someone was offended by your use of the h1 tag. Oct 4, 2010 at 20:58
• @Chaos: That's the essential answer. Oct 4, 2010 at 21:16
• 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. Oct 4, 2010 at 21:25

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.

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.
• Nᴏʙᴏᴅʏ expects the Spanish... ah bugger, I'm a bit late here. Oct 4, 2014 at 1:07

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.