Menu
What are the advantages of using multiple source (.cpp) and header (.h) files in a single project?
Is it just a preferential thing or are there true benefits?
703
To prevent the requirement of downloading ginormous files, scripts can be split into multiple smaller files. Then features required at page load can be downloaded immediately with additional scripts being lazy loaded after the page or application is interactive, thus improving performance.
A large C or C++ program should be divided into multiple files. This makes each file short enough to conveniently edit, print, etc. It also allows some of the code, e.g. utility functions such as linked list handlers or array allocation code, to be shared with other programs.
Code is easier to read Modular programming usually makes your code easier to read because it means separating it into functions that each only deal with one aspect of the overall functionality. It can make your files a lot smaller and easier to understand compared to monolithic code.
It helps you split your code and sort it by theme. Otherwise you get one file with 1000s of lines… which is hard to manage…
Usually, people have .h and .c for one or sometimes a few classes. Also, it speeds up compilation, since only the modified files, and some related files need to be recompiled.
From Organizing Code Files in C and C++:
Splitting any reasonably-sized project up buys you some advantages, the most significant of which are the following:
Speed up compilation - most compilers work on a file at a time. So if all your 10000 lines of code is in one file, and you change one line, then you have to recompile 10000 lines of code. On the other hand, if your 10000 lines of code are spread evenly across 10 files, then changing one line will only require 1000 lines of code to be recompiled. The 9000 lines in the other 9 files will not need recompiling. (Linking time is unaffected.)
Increase organization - Splitting your code along logical lines will make it easier for you (and any other programmers on the project) to find functions, variables, struct/class declarations, and so on. Even with the ability to jump directly to a given identifier that is provided in many editors and development environments (such as Microsoft Visual C++), there will always be times when you need to scan the code manually to look for something. Just as splitting the code up reduces the amount of code you need to recompile, it also reduces the amount of code you need to read in order to find something. Imagine that you need to find a fix you made to the sound code a few weeks ago. If you have one large file called GAME.C, that's potentially a lot of searching. If you have several small files called GRAPHICS.C, MAINLOOP.C, SOUND.C, and INPUT.C, you know where to look, cutting your browsing time by 3/4.
Facilitate code reuse - If your code is carefully split up into sections that operate largely independently of each other, this lets you use that code in another project, saving you a lot of rewriting later. There is a lot more to writing reusable code than just using a logical file organization, but without such an organization it is very difficult to know which parts of the code work together and which do not. Therefore putting subsystems and classes in a single file or carefully delineated set of files will help you later if you try to use that code in another project.
Share code between projects - The principle here is the same as with the reuse issue. By carefully separating code into certain files, you make it possible for multiple projects to use some of the same code files without duplicating them. The benefit of sharing a code file between projects rather than just using copy-and-paste is that any bug fixes you make to that file or files from one project will affect the other project, so both projects can be sure of using the most up-to-date version.
Split coding responsibilities among programmers - For really large projects, this is perhaps the main reason for separating code into multiple files. It isn't practical for more than one person to be making changes to a single file at any given time. Therefore you would need to use multiple files so that each programmer can be working on a separate part of the code without affecting the file that the other programmers are editing. Of course, there still have to be checks that 2 programmers don't try altering the same file; configuration management systems and version control systems such as CVS or MS SourceSafe help you here. All of the above can be considered to be aspects of modularity, a key element of both structured and object-oriented design.
Then, they go on about How to do it, Potential Pitfalls, Fixing problems, etc.
You should check it.
80
Code files become unmaintainable (try searching in them!) after a few hundred lines. Some people go up to a few thousand (but this is already a problem). Even small projects have thousands of lines, medium projects have tens of thousands of lines, and big projects have millions of lines. Text editors cannot cope with files this big (but programmers themselves cannot either).
Splitting a project into different source files is also necessary if you want to separate your project into different compilation units, which makes compilation much faster because only parts of the projects need to be recompiled.
A few decades ago programs used to be written in one single file / stack of cards. However, these programs were tiny in comparison to modern programs, and completely unmaintainable – even small changes essentially necessitated a rewrite, which put a fixed upper limit on the complexity that could thus be achieved.
Modern, more complex projects essentially require splitting apart. The question of putting everything in one file is frankly one that I’ve never asked myself because the idea is simply inconceivable.
35
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
