包括文件排序策略

Question

我看到了相当一致的建议，即实现文件（.cc / .cpp）应包含其相应的类 首先定义文件，然后再包含其他头文件。但是，当主题转向头文件本身及其包含的包含顺序时，建议似乎有所不同。

Google 编码标准建议：

1. dir2/foo2 .h（首选位置 - 请参阅下面的详细信息）。
2. C 系统文件。
3. C++ 系统文件。
4. 其他库的 .h 文件。
5. 您项目的 .h 文件。

目前尚不清楚上述条目 1 和条目 5 之间有何区别，以及为何选择其中一个或另一个位置。也就是说，另一个在线指南建议了这个顺序（可以在“类布局”部分找到）该文档）：

1. 系统包含
2. 项目包含
3. 本地包含

再次出现歧义，这次是在第 2 项和第 3 项之间。有什么区别？这些是否代表项目间和项目内包含？

但更重要的是，看起来两个提议的编码标准都建议最后包含“您的”头文件。这种建议与实现文件中包含排序的建议相反，并不直观。将“您的”头文件始终列在前面 - 在系统头文件和第 3 方头文件之前没有意义吗？

Answer 1

从技术角度来看，您列出的内容的顺序并不重要。如果设计正确，您应该能够按照您想要的任何顺序放置它们，并且它仍然可以工作。例如，如果您的 foo.h 需要 ，它应该包含在您的 foo.h 中，这样您就不需要在任何使用 foo 的地方都要记住这种依赖关系。

话虽这么说，如果您确实有顺序依赖性，大多数时候将定义文件放在最后会修复它。这是因为 foo.h 依赖于 ，但反之则不然。

您可能认为这是将定义文件放在最后的一个很好的例子，但实际上恰恰相反。如果您的编码标准要求首先定义，那么您的编译器更有可能在首次编写时捕获不正确的顺序依赖项。

Answer 2

我不知道有任何逐字标准，但作为一般经验法则，应包含尽可能少的标头，尤其是在其他标头文件中，以减少编译时间、冲突和依赖性。我喜欢在头文件中使用类的前向声明，并且只要我有能力，就只在 .cpp 端包含头文件和定义。

也就是说，我个人的偏好如下：

对于标头：

1. C++ 标头
2. 第 3 方标头
3. 其他项目标头
4. 该项目的标头

对于源：

1. 预编译头文件
2. 该源文件的标头
3. C++ 标头
4. 第 3 方标头
5. 其他项目标头
6. 该项目的标头

通常要避免的指针或建议冲突和循环引用，否则这都是个人偏好或您喜欢遵守协作项目的任何政策。

Answer 3

关于谷歌的风格：

一点也不含糊。

包含的第一个标头应该是与 this 源文件相关的标头，因此位于位置 1。通过这种方式，您可以确保它包含所需的任何内容，并且不存在“隐藏”依赖项：如果存在，它会立即暴露并阻止编译。

其他标头按照您最不可能更改的标头排序（如果您最有可能更改的标头出现问题）。问题可能是标识符冲突、宏泄漏等……

根据定义，C 和 C++ 系统头文件很少被更改，仅仅是因为有很多人使用它们，因此它们排在第二位。

第三方代码可以更改，但通常很麻烦并且需要时间，因此它们排在第三位。

“项目包含”指的是项目范围的包含，通常是由多个项目使用的自制库（中间件）。它们可以改变，但这也会影响其他项目，它们排在第四位。

最后是“本地包含”，即特定于该项目的那些文件，可以在不影响其他任何人的情况下进行更改。如果出现问题，这些是主要候选人，他们是最后的。

请注意，实际上您可以有更多层（尤其是在软件商店中），关键思想是从底层（系统库）到顶层对依赖项进行排序。

在给定的层中，我倾向于按字母顺序组织它们，因为这样更容易检查它们。

Answer 4

对于标题：
这个项目的标题
其他项目标题
第 3 方标头
源代码的C++ 标头

：
这个源文件的头
这个项目的标题
其他项目标题
第 3 方标头
C++ 标头

此命令可最大程度地减少在 .hpp 文件中遗漏某些所需标头的机会。它还最大限度地减少了第 3 方标头等的交集。并且所有 hpp 模块都以最小所需的依赖项进行编译。

例如：
->test.hpp

// missing #include <string> header
void test(std::string& s);

->test.cpp

#include <string> 
#include "test.hpp"
// we hide bug with missing required header 

->test2.cpp

#include "test.hpp"
#include <string> 
// compilation error with missing header