Take the 2-minute tour ×

I'm finding lots of 2-3k line files, and it doesn't really feel like they should be that big.

What is a good criteria to objectively call a source code file "too big"?, is there such thing as a maximum amount of lines a source code file should have?

share|improve this question
Your peer tells you after reviewing the code. "You cannot determine this yourself because you know more as the author than the code says by itself. A computer cannot tell you, for the same reasons that it cannot tell if a painting is art or not. Hence, you need another human - capable of maintaining the software - to look at what you have written and give his or her opinion..." –  gnat Nov 24 '12 at 14:22
Some compilers used to have weird limits on source code size: max line length or max number of lines. When compiler complains, this is an objective indicator that code is too big (or that it is time to upgrade). –  mouviciel Nov 25 '12 at 11:17
Split as much as possible, but without breaking the integrity of files. Each file (or pair of header/source files) should always be a rounded whole, independent of the internal implementation of other files. If this means some files will be large because they implement something complex, so be it. –  Ambroz Bizjak Nov 25 '12 at 11:25

3 Answers 3

up vote 3 down vote accepted

As an ideal model I use the following criteria (with a similar rationale to what Martin Beckett suggested, i.e. to think in terms of logical structure and not in terms of lines of code):

Rule 1

One class per file (in C++: one class -> one header and one implementation file).

Rule 2

Seven is considered the number of items that our brain can observe at the same time without getting confused. Above 7 we find it difficult to keep an overview of what we see. Therefore: each class should not have more than 7-10 methods. A class that has more than 10 method is probably too complex and you should try to split it. Splitting is a very effective method because every time you split a class you reduce the complexity of each individual class at least by a factor of 2.

Rule 3

A method body that does not fit in one or two screens is too big (I assume that a screen / editor window is about 50 lines). Ideally, you can see the whole method in one window. If this is not the case, you only need to scroll up and down a bit, without forgetting the part of the method that gets hidden. So, if you have to scroll more than one screen up or down to read the whole method body, your method is probably too big and you can easily lose the overview.

Again, splitting methods using private help methods can reduce method complexity very fast (at every split the complexity is at least halved). If you introduce too many private help methods you can consider creating a separate class to collect them (if you have more private methods than public ones, maybe a second class is hiding inside your main class).

Putting together these very rough estimates:

  • At most one class per source file.
  • At most 10 public method per class.
  • At most 10 private method per class.
  • At most 100 lines per method.

So a source file that is more than 2000 lines is probably too large and starting to be too messy.

This is really a very rough estimate and I do not follow these criteria systematically (especially because there is not always enough time to do proper refactoring). Also, as Martin Beckett suggested, there are situations in which a class is a large collection of methods and it does not make sense to split them in some artificial way just to make the class smaller.

Anyway, in my experience a file starts to get unreadable when one of the above parameters is not respected (e.g. a 300 line method body that spans six screens, or a source file with 5000 lines of code).

share|improve this answer
Disagree with #2: what about overloads? For example ostream << operator in C++ has a large number of similar methods, but fundamentally all do the same thing (write to the stream). –  JBRWilkinson Nov 26 '12 at 12:00
@JBRWilkinson: See the paragraph towards the end of the answer. –  Giorgio Nov 26 '12 at 13:39

No - not in terms of lines of code. The driver should be logical grouping. There certainly shouldn't be multiple classes in one large file for example

If you had a class that legitmately had a few hundred methods (not impossible in say 3D modelling) it would be a lot less convenient to split that into arbitrary files. We used to have to do this when memory was scarcer and processors slower - and it was a pains, constantly searching for the function definition.

share|improve this answer
@user1598390: usually, but not always. –  whatsisname Nov 24 '12 at 2:26
@user1598390 - common in say gis/3d modelling to have lots of operations you can perform, and then have them overloaded for 2d,3d,4d,3d+signal,then float/double/integer etc - templates help a little but for efficency lots of operations are often better than a pretty class heirarchy –  Martin Beckett Nov 24 '12 at 3:01
@dukeofgaming - either irony, or we have found the reason behind Microsoft Bob –  Martin Beckett Nov 24 '12 at 23:19
@tp1 - and you use a small font so they don't take up as much space? –  Martin Beckett Dec 3 '12 at 16:10
@tp1 - you use different classes? Doesn't that make it complex remembering the names? –  Martin Beckett Dec 4 '12 at 5:13

When the code in it becomes unmaintainable. i.e: you can't tell just by watching the code if the method/class/function you're looking for (and have to edit/debug) is in there, or not, and if so, where it is.

Your IDE/Editor choice and features will influence this upper limit's actual quantification, though. Code folding, function/method listing, and lookup will postpone the moment this development scenario presents.

But when it does, it's time to split it.

share|improve this answer

Your Answer


