Is it a good idea to put all of your includes in one header file?

Question

What is the best practice for C what you put into a C header file?

Is it useful to put all the includes used for a program across multiple source files in one header

Answer 1

Personal preference really... It doesn't matter how it is formatted as long as you are consistent (which makes it easy to read). You could put it all in 1 header file or you can just put it in every file that needs it. It also depends on how other includes are loaded anything that comes after the main doesn't need its includes and so on so using the same header file for ALL your other C files may or may not (depends on compiler) include the same include multiple times.

Edit: I have to agree with Mac too, put it where you use it is a very, very nice thing to do as well

Answer 2

I wouldn't purposely put all my includes into a single header file, simply because if you change one of these included header files, you'll have to recompile everything that has included your "master" include file. This can lead to unnecessarily long compilation times for a single line change.

That said, I wouldn't put too much time in making sure I'm not being too liberal with include statements. Some engineers will spend lots of time trying to reduce includes to save on compilation time, and I think their time is better served solving problems or working on new features.

Answer 3

A header file is actually what you include from your c program. It containts data structures like structs, macros, function definitions etc.. Sometimes a single header file can be ok, buy if your program grows into logical components, you may need more.

Answer 4

Some things not already pointed out:

• unneeded dependancies add to the compile time. When you modify an header, you'll have to recompile all compilation units which include it directly or indirectly. If the inclusion is not needded, the recompilation isn't either. The larger your program is, the bigger will be the problem, especially if you have broken your programs into composants whose recompilation your have to trigger manually.

• pre-compiler headers may be more efficient when you add unneeded dependencies.

Answer 5

I personally subscribe to a "put it where you use it" philosophy. It makes it much clearer which files use what, where dependencies are, etc.

Imagine you have a header MyHeader.h. If you make a change in it that requires changing code that relies on it, it's easy to find that dependent code if each file that uses it has a #include "MyHeader.h" - you can just do a global search for the include statement.

If on the other hand you only include MyHeader.h in some other header MyHugeHeader.h, and then include that in your files you can't do the same, since all that's in the files that use MyHeader.h is #include "MyHugeHeader.h", same as every other file.

Answer 6

Putting all possible headers in one application header is as wrong as wrong can be.

This is laziness that comes at a great price. It makes builds brittle. It makes it hard to understand where true dependencies are, and thus hard to refactor or otherwise re-use code.

It makes it hard to test.

But the biggest problem is that it represents intellectual laziness and encourages more of the same.

As will all programming issues, do what is needed, no more, no less. Think about maintainence. Think about build management.

Just THINK.