Some books or master told us this principle: Equal or less than 15 lines per method(function), and the perfect is under(or equal) 8 lines.

Does the principle make sense for most conditions?

There are many cases break the principle in Windows OSX Android UNIX SDKs, so how to deal with the principle?

What are the exceptions for this principle?

Is it worth to take a lot of time to refactor exist code to fit this principle?

How about call another method just at 15th line?(kidding)

  • 1
    There is a reason behind this principle: your mind can only keep track of a few "things" at a time (as far as I can remember, one normally cannot visualize more than 7 objects at the same time). So when a function gets larger than 15 lines (about twice as much as 7) it gets more and more difficult to understand. So a few minutes spent today breaking up a complex function into smaller ones will probably save many hours of debugging six months later.
    – Giorgio
    Commented Aug 14, 2014 at 7:23
  • 2
    Question will most likely get closed as opinion based. Basically this is a good rule of thumb. The exact amount of lines may depend a bit, some languages tend to do less in a single lines while others allow you to write something like quicksort in a single line. Commented Aug 14, 2014 at 7:27
  • 2
    A lot of well used and reputable free software don't follow that rule blindly (e.g. Linux kernel, GCC, ....); BTW would you find a book made of only 15 lines chapters very readable? Commented Aug 14, 2014 at 8:05
  • @BasileStarynkevitch: well, a book is quite different compared to source code, so it's not an easy comparison. Commented Aug 14, 2014 at 8:13

1 Answer 1


I hear "rules" like this all the time, but it's all to easy to try too hard to adhere to these types of rules.

I've seen code where functions are broken into illogical blocks simply to keep functions short.

I'd say that common sense is the best rule.

No one is ever going to be able to come up with a number that works in every situation. If you find a logical block of statements that can be refactored into a new method, do it and you should find your method lengths as reasonable as possible.

If you can't, but you notice that methods are getting unreasonably long, take it not as a sign you should raze them down to an arbitrary number of lines, but that maybe something else needs to be refactored, for example, maybe the class as a whole has too much responsibility.

Edit: SJuan76 also brings up an excellent point:

Q: When is 15 lines of code not really 15 lines of code?

A: When it's 15 lines of logging values/trival input validation/(etc.)

That's one of the biggest pitfalls of using lines of code as a metric, even if it's a narrow case like this. Lines of code don't convert/equate to any useful measure of "work". In one environment 10 lines might just be enough to configure an error logger, in another, 2 lines might be enough, I'd say in both cases would merit one method.

  • Also, keep in mind to take into account the programming style. If you are programming defensively, you might very well spend most of these 15 lines just checking the input parameters & logging... but such a code usually does not add to the complexity of the code (IMO, it reduces it since your code needs to cover less cases) and how easy it is to read it.
    – SJuan76
    Commented Aug 14, 2014 at 7:57
  • That's a great point, I just added a mention of it in the answer. Commented Aug 14, 2014 at 8:06
  • Decades of programming has taught me that "common sense" can mean very different things to different people. I recommend being specific. Commented Aug 14, 2014 at 11:10
  • Also the very word rule makes me cring. Should be a guideline Commented Aug 14, 2014 at 11:10
  • and finally, for the issue at hand - in ruby I try to follow a recommendation of 5 lines per method and 100 lines per class :) Commented Aug 14, 2014 at 11:11

Not the answer you're looking for? Browse other questions tagged or ask your own question.