Question

在包含其他头文件之前，我已经看到一个相当一致的建议，即实现文件（.cc / .cpp）应该包含其对应的类definition file first。但是当主题转移到头文件本身，以及它们包含的包含顺序时，建议似乎会有所不同。

目前尚不清楚上述第1项和第5项之间的差异，以及选择其中一个或另一个地点的原因。也就是说，another online guide建议这个顺序（在该文档的“类布局”部分中找到）：

这一次又出现了歧义，这次是第2项和第3项之间的区别。有什么区别？这些代表项目间和项目内部包括吗？

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

Answer 1

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

那说我的个人偏好如下：

对于标题：

来源：

指针或建议通常是为了避免冲突和循环引用，否则这些都是个人偏好或您希望在协作项目中遵守的任何政策。

Answer 2

从技术角度来看，列出您的包含的顺序无关紧要。如果你设计得对，你应该能够按照你想要的任何顺序放置它们，它仍然可以工作。例如，如果您的foo.h需要<string>，那么它应该包含在您的foo.h中，这样您就无需在使用foo的任何地方记住该依赖项。

话虽这么说，如果你做有订单依赖，大多数时候把你的定义文件放在最后将修复它。这是因为foo.h取决于<string>，而不是相反。

您可能认为这样可以最好地将您的定义文件放在最后，但事实恰恰相反。如果您的编码标准首先需要定义，那么编译器在首次编写时更有可能捕获不正确的顺序依赖性。

Answer 3

关于Google的风格：

根本没有歧义。

包含的第一个头应该是与this源文件相关的头，因此在位置1.这样你就可以确保它包含它需要的任何东西，并且没有“隐藏”依赖：如果有，它会立即曝光并阻止编译。

如果您更有可能发生问题，那么其他标题会从您最不可能更改的标题中排序。问题可能是标识符冲突，宏观泄漏等......

根据定义，C和C ++系统标题很少被改变，只是因为有很多人使用它们，因此它们排在第二位。

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

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

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

请注意，您实际上可以拥有更多层（特别是在软件商店中），关键的想法是从底层（系统库）到顶层订购依赖项。

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

Answer 4

标题：该项目的标题其他项目标题第三方标题 C ++标头

对于来源：该源文件的头该项目的标题其他项目标题第三方标题 C ++标头

此命令最大程度地减少了在.hpp文件中缺少某些必需标头的机会。同时，它也最小化了第三方标头等的交集。并且所有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