我的项目有几个头文件。大多数 C 源文件都包含所有这些，因此几乎每个源文件都包含以下行：
#include "add.h"
#include "sub.h"
#include "mul.h"
#include "div.h"
#include "conv.h"
#include "comp.h"
// etc.
这应该移到某个all.h或类似的地方吗？有没有更好的方法可以做到这一点？
在每个.c文件中，应该很容易知道它需要什么。按照自己的方式，您可能会忘记它需要的内容，而另一位同事将需要查找此文件。
换句话说，你不应该这样做，因为你在代码中失去了清晰度。
还有第三个选项，在中间的某个地方，对几乎所有翻译单元共享的内容(例如，像stdint.h这样的标题)有一个最低common.h。或者，您可能决定将add.h、sub.h和类似的标头分组到单个ops.h标头中。
但是，实际上只有一个all.h标头会使隐藏在C中的封装/信息比现在更难。宇宙飞船微控制器中的数学库真的需要了解有关生命支持系统的所有信息吗？
当然，C 并没有真正的"一类封装机制"，你几乎可以在任何地方抛出一个extern函数声明，这就是为什么坚持合理的约定和最佳实践相当重要的原因。
这两种方法都有优点和缺点(有一个all.h包括所有标题，或者不)，所以这也是一个意见问题。在一个相当小的项目中，拥有一个包含所有公共声明(以及static inline函数定义)的头文件也是可能的。
另请参阅此答案(其中给出了两种方法的示例)。
只有一个标头(包括其他标头，甚至系统标头)的可能原因是启用该标头文件的预编译。请参阅此答案(以及那里的链接)。
支持多个头文件的一个可能原因是可读性和模块化。您可能希望每个模块有一个(相当小的)头文件，并且在每个翻译单元(几乎每个.c文件)中，您只会包含最少的头文件集(按良好顺序)。
请记住，C99和C11(甚至C++14)没有任何模块的概念;换句话说，C语言中的模块只是约定和习惯的问题。约定和习惯在C程序中非常重要，所以看看其他人在现有的自由软件项目中做了什么(例如在github或sourceforge上)。
请注意，预处理是大多数 C 编译器的第一阶段。阅读有关 C 预处理器的文档。
你实际上会使用像GNU make这样的构建自动化系统。您可能希望自动生成依赖项(例如，像这里一样)。
对于一个人的项目(最多几十万行源代码)，我个人更喜欢有一个头文件，但这是一个意见和品味的问题(所以很多人不同意)。顺便说一句，当项目变得足够大时重构项目(到几个头文件)很容易(但更难设计);您只需将一些代码块复制并粘贴到几个新的头文件中。
对于涉及多个开发人员的项目，您可能希望支持大多数文件(标头或代码)都有一个开发人员负责它们的想法(其他开发人员偶尔对其进行更改)。
请注意，标头包含和预处理是一种文本操作。理论上，您甚至可以避免使用头文件，并在.c文件中复制和粘贴相同的声明，但这是非常糟糕的做法，因此您不应该这样做(在手写代码中)。但是，一些项目正在生成C 代码(某种元编程)，它们的 C 代码生成器(一些脚本或一些工具，如 bison)可以在多个文件中发出相同的声明。