我是一名程序员多年。
我总是被告知（并告诉其他人）你应该在你的.c文件中只包含你需要的.h文件。没什么，没什么。
但让我问 - 为什么？
使用今天的编译器我可以包含项目的整个h文件，它不会对编译时间产生巨大影响。
我不是在谈论包含OS .h文件，其中包括许多定义，宏和预处理命令。
只包含一个“MyProjectIncludes.h”。那只会说：
#pragma once
#include "module1.h"
#include "module2.h"
// and so on for all of the modules in the project
你说什么？
答案 0 :(得分：3)
由于包含太多标头，因此.c文件的编译时间不长。如你所说，包含一些额外的标题可能不会对该文件的编译时间产生太大影响。
真正的问题是，一旦您将所有.c文件都包含“主”头文件，那么每次更改任何.h文件时，每个.c文件都需要重新编译 ，因为您使每个.c文件都依赖于每个.h文件。因此，即使您执行了一些无关紧要的操作，例如添加只有一个文件将使用的新#define，您将强制重新编译整个项目。如果您与团队合作并且每个人经常更改头文件，情况会更糟。
如果重建整个项目的时间很短，例如不到1分钟，那么这并不重要。我承认，为了方便起见，我已经完成了你在小项目中的建议。但是，一旦您开始处理需要几分钟才能重建所有内容的大型项目，您将会欣赏需要重建一个文件与重建所有文件之间的区别。
答案 1 :(得分：1)
它会影响您的构建时间。此外，您还有冒circular dependency
的风险答案 2 :(得分：1)
通常，您不希望重新编译模块，除非它们实际依赖的标题已更改。对于较小的项目，这可能无关紧要，全局“include_everything.h”文件可能会使您的项目变得简单。但是在大型项目中，编译时间可能非常大，最好尽量减少模块间的依赖关系。最小化包含不必要的标题只是一种方法。使用仅由指针或引用引用的类型的前向声明，使用Pimpl模式，接口和工厂等，都是旨在减少模块之间的依赖性的方法。这些步骤不仅减少了编译时间，而且还可以使您的系统更容易测试，更容易修改。
是一个关于这个主题的优秀但有点过时的参考文献答案 3 :(得分：-1)
当然，就像你说过的那样，包括额外的文件会对你的编译时间造成太大的伤害。就像你建议的那样，使用1 include line转储所有内容会更方便。
但是如果他们确切知道您在特定.h文件中使用了哪些.c文件，那么您是否觉得陌生人可以更好地理解您的代码？对于初学者，如果您的代码存在任何错误，并且这些错误位于.h文件中，则他们确切地知道要检查哪些.h文件。