What is a good amount of code to have in a single file?

Question

I was wondering today about how much code people normally have in a single source file before they decide to split it into multiple smaller files.

Personally I tend to keep my files fairly small (exspecally header files when working with C/C++). That is I will generally only have one class or a bunch of functions in a given file so the file is generaly <500 lines. However all the stuff related normally shares the same namespace.

On the other hand some of the stuff I work with seem to quite happily try to stick as much as possible into a single file which is then 1000's of lines long.

I like the small files better since any changes only requires recompiling that one piece of code, and I find it easier to navigate the source when it is broken into smaller files each with a specific purpose, rather than one massive file about the entire thing. Is there any real advantage to a few massive files?

For example my particle system is broken into system.h, emitter.h, load.h, particle.h, etc and corosponding .cpp files for each one. However some particle systems ive looked at seem to have put the entire source into a single .h and .cpp 1000's of lines long.

Answer 1

I'm not aware of any globally enforced standard for this.

Code should be well documented, like having comments or the code being unambiguous enough to not needing comments at all, so easy to read and understand, that's priority.

But splitting one huge class/method into smaller ones is generally good idea.

If there's no logical need to have your class/method be longer than 300 lines, it should probably be at least half that short.

Answer 2

Having too little in each source file is just as bad as having too much - the cluttering only moves from being in the individual source file to the project itself.

When I notice that a sourcefile starts to deal with two (or more) clearly separate aspects, I tend to split it.

I also split it if I have a sense that it contains functions that are likely to be modified a lot in the future, while also having functions that are likely to be stable.

Answer 3

It depends of course, you can not limit yourself to a standard. But I read in a article that

your methods should be a screen wide, so you can see what happens in it without scrolling,

your parameters to methods should be less or equal to 7, and your inheritance depth should be less or equal to 3 which is a good amount for a human to understand without difficulty.

In my opinion the limit for a file is should be it's responsibility. Each file should require it's own class and each class should have one responsibility.

Answer 4

I split all the different parts of my project up into different files, mainly for the compile time that is associated with it. When the objects already exist for the CC files I need to link in, I don't have to recompile those from scratch.

Deciding between a monolithic and or smaller files should be a team decision and should be set forth in the coding rules each programmer on the team is following, just like there is guidelines on tabs/spaces used there should be guidelines on how to add new code to the project.

For certain projects it makes more sense to have as much of the code together, especially if using just one single part of the project without the rest of it makes the entire thing practically useless. It is a trade-off that you have to weigh the pro's and con's to and ultimately you have to decide which one is going to work better for you.

That being said, many smaller files allows for easier development by multiple developers using a versioning system much like Perforce as it makes changes one developers makes less likely to cause commit issues that need to be resolved when another developer works on another piece of the code.

Answer 5

If you are not expecting the code to change then a gigantic single file can be more convenient for the user. For example SQLite distribute their code as a monolithic source file that the user can easily incorporate into their own build.

However, during development it is a terrible idea, for the reasons you mention and also because it almost guarantees that there will be RCS merge problems when more than one programmer is working on the project.

Answer 6

You should identify the software modules in terms of logically not physically. So you should design the classes/functions depending upon the responsibility.

You can use CRC approach to identify the responsibility of each class.

Answer 7

Smaller files are without any doubt easier to read and understand. However, I don't think you can make this decision based on the number of lines in a class or source file. Consider splitting up your code if you feel that common functionality should be placed in a different file instead. It will also allow for better reuse of code.