Take the 2-minute tour ×

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?

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

closed as not constructive by MichaelT, Martijn Pieters, gnat, Kilian Foth, Jimmy Hoffa Mar 18 '13 at 13:02


7 Answers

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

share|improve this answer
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. –  ChaosPandion Oct 4 '10 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. –  Lorenzo Oct 4 '10 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. –  ChaosPandion Oct 4 '10 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? –  gablin Oct 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. –  grokus Oct 5 '10 at 14:52
show 2 more comments

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.

share|improve this answer
This metric becomes progressively more useless as average monitor size/resolution increases. –  Anna Lear Oct 4 '10 at 20:40
Our programming prof just said this example the other night :) –  cdnicoll Oct 4 '10 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! :) –  Lorenzo Oct 4 '10 at 20:43
+1 read this in Code Complete, seemed to make sense. –  Peter Turner Oct 4 '10 at 21:03
The 24 x 80 size of a terminal doesn't tend to change. –  alternative Oct 4 '10 at 21:31
show 8 more comments

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.

share|improve this answer
Least you could do is tell my why you think my answer isn't useful. –  Josh K Oct 4 '10 at 20:56
I think someone was offended by your use of the h1 tag. –  ChaosPandion Oct 4 '10 at 20:58
@Chaos: That's the essential answer. –  Josh K Oct 4 '10 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. –  ChaosPandion Oct 4 '10 at 21:25
add comment

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.


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.

share|improve this answer
add comment

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

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.
share|improve this answer
add comment
