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