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

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.

Answer 2

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 3

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

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.