2

I'm a programmer for several years.

I was always told (and told others) that you should include in your .c files only the .h files that you need. Nothing more, nothing less.

But let me ask - WHY?

Using today's compilers I can include the entire h files of the project, and it won't have a huge effect on compilation times.

I'm not talking about including OS .h files, which include many definitions, macros, and preprocessing commands.

Just including one "MyProjectIncludes.h". That will only say:

#pragma once
#include "module1.h"
#include "module2.h"
// and so on for all of the modules in the project

What do you say?

user972014
  • 3,296
  • 6
  • 49
  • 89
  • 15
    *"I can include the entire h files of the project, and it won't have a huge effect on compilation times."* Then you are not working in a very large code base. – Cory Kramer Nov 03 '14 at 21:10
  • 2
    Think not only of compilation time, but of building time. The build process has determined a relationship between modules that need compilation and those that don't. So, compiling a module that has not changed and does not depend on a changed file is a waste of time and resources. – Thomas Matthews Nov 03 '14 at 21:11
  • 2
    This is the theory behind precompiled headers - compile the big ball of headers once, then just read the result into every source file without recompiling. – Mark Ransom Nov 03 '14 at 21:13
  • 2
    Even if built times were not affected, there is a readability benefit to having each module detail its dependencies. – salezica Nov 03 '14 at 21:22

4 Answers4

3

It's not about the compilation time of your .c file taking longer due to including too many headers. As you said, including a few extra headers is not likely going to make much of a difference in the compilation time of that file.

The real problem is that once you make all your .c files include the "master" header file, then every time you change any .h file, every .c file will need to be recompiled, due to the fact that you made every .c file dependent on every .h file. So even if you do something innocuous like add a new #define that only one file will use, you will force a recompilation of the whole project. It gets even worse if you are working with a team and everyone makes header file changes frequently.

If the time to rebuild your entire project is small, such as less than 1 minute, then it won't matter that much. I will admit that I've done what you suggested in small projects for convenience. But once you start working on a large project that takes several minutes to rebuild everything, you will appreciate the difference between needing to rebuild one file vs rebuilding all files.

JS1
  • 4,745
  • 1
  • 14
  • 19
1

It will affect your build times. Also, you run the risk of having a circular dependency

Lawrence Aiello
  • 4,560
  • 5
  • 21
  • 35
1

In general you don't want to have to re-compile modules unless headers that they actually depend on are changed. For smaller projects this may not matter and a global "include_everything.h" file might make your project simple. But in large projects, compile times can be very significant and it is preferable to minimize inter-module dependencies as much as possible. Minimizing includes of unnecessary headers is only one approach. Using forward declarations of types that are only referenced by pointers or references, using Pimpl patterns, interfaces and factories, etc., are all approaches aimed at reducing dependencies amongst modules. Not only do these steps decrease compile time, they can also make your system easier to test and easier to modify in general.

An excellent, though somewhat dated reference on this subject, is John Lakos "Large Scale Software Design".

sfjac
  • 7,119
  • 5
  • 45
  • 69
-1

Sure, like you've said, including extra files won't harm your compilation times by much. Like what you suggest, it's much more convenient to just dump everything in using 1 include line.

But don't you feel a stranger could get better understanding of your code if they knew exactly what .h files you were using in a specific .c file? For starters, if your code had any bugs and those bugs were in the .h files, they'd know exactly which .h files to check up on.

lennon310
  • 12,503
  • 11
  • 43
  • 61
Kelvin Lau
  • 6,373
  • 6
  • 34
  • 57
  • Not really. Because each h files includes a few more, and it includes several others. I find myself maintaining the list of .h files to include in every file... Pretty annoying – user972014 Nov 03 '14 at 21:27