问题
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 file?
What about includes that are used in practically every file (i.e. stdio.h)?
回答1:
No. It simply adds cruft and overhead.
One of the biggest pains that you'll face as a maintainer is figuring out what headers don't need to be included and get rid of them. Whe you get to a list of 20+ headers, you start contemplating ugly things like brute forcing through it (removing one at a time and seeing if anything breaks).
Be kind to people who have to maintain your stuff in the future. Use the headers you need per module, no more .. no less :)
回答2:
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.
回答3:
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.
回答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.
回答5:
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
回答6:
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.
回答7:
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.
来源：https://stackoverflow.com/questions/5138259/is-it-a-good-idea-to-put-all-of-your-includes-in-one-header-file