我建议:

正在构建的.cc模块的头文件。(有助于确保项目中的每个头文件对项目中的其他头文件没有隐式依赖。) C系统文件。 c++系统文件。 平台/操作系统/其他头文件(例如win32、gtk、openGL)。 项目中的其他头文件。

当然，在可能的情况下，每个部分都要按字母顺序排列。

总是使用前向声明来避免在头文件中包含不必要的#。

我很确定这在任何理智的世界里都不是一个推荐的实践，但我喜欢按文件名长度排列系统包含，在相同的长度内按词法排序。像这样:

#include <set>
#include <vector>
#include <algorithm>
#include <functional>

我认为在其他人之前包含自己的头文件是一个好主意，以避免包含顺序依赖的耻辱。

给自己添砖加瓦。

每个头文件都需要是自给自足的，只有当它至少被首次包含一次时，才能对其进行测试 不应该通过引入符号(宏、类型等)来错误地修改第三方标头的含义。

所以我通常是这样的:

// myproject/src/example.cpp
#include "myproject/example.h"

#include <algorithm>
#include <set>
#include <vector>

#include <3rdparty/foo.h>
#include <3rdparty/bar.h>

#include "myproject/another.h"
#include "myproject/specific/bla.h"

#include "detail/impl.h"

每组之间用空行分隔:

第一个对应于此cpp文件的头(健全性检查) 系统头文件 第三方头文件，按依赖顺序组织 项目标题 项目私有头文件

还要注意，除了系统头文件外，每个文件都位于一个与其名称空间同名的文件夹中，因为这样更容易跟踪它们。

要记住的一件重要的事情是，您的头文件不应该依赖于首先包含的其他头文件。确保这一点的一种方法是在任何其他头文件之前包含您的头文件。

《c++思维》特别提到了这一点，引用了Lakos的《大规模c++软件设计》:

可以通过确保组件的.h文件自己进行解析来避免潜在的使用错误——没有外部提供的声明或定义……将.h文件作为.c文件的第一行，可以确保.h文件中不缺少组件物理接口固有的关键信息(或者，如果有的话，在尝试编译.c文件时就会发现它)。

也就是说，按以下顺序包括:

这个实现的原型/接口头文件(即.h/。对应于.cpp/. Hh文件。cc文件)。 同一项目中的其他头文件，视需要而定。 来自其他非标准、非系统库(例如Qt、Eigen等)的头文件。 来自其他“几乎标准”库的头文件(例如，Boost) 标准c++头文件(例如iostream, functional等) 标准C头文件(例如，cstdint, direct .h等)

如果任何标题在这个顺序中有问题，要么修复它们(如果你的)，要么就不要使用它们。抵制不编写干净头文件的库。

谷歌的c++风格指南几乎完全相反，没有任何正当理由;我个人倾向于Lakos方法。

在决定特定的包含顺序时，需要合并几个单独的考虑事项。让我试着理清头绪。

1. 检查自制力

许多回答认为，include顺序应该作为头文件是否自包含的检查。这就混淆了测试和编译的考虑

您可以单独检查您的头文件是否自包含。“静态分析”是独立于任何编译过程的。例如，运行

gcc headerfile.h -fsyntax-only

测试头文件是否自包含可以很容易地编写脚本/自动化。甚至你的makefile也可以这样做。

无意冒犯，但Lakos的书是1996年的，把这些不同的问题放在一起听起来像90年代风格的编程。也就是说，有些生态系统(现在的Windows还是90年代的Windows ?)缺乏脚本/自动化测试的工具。

2. 可读性

另一个考虑因素是可读性。当您查找源文件时，您只想轻松地查看包含了哪些内容。因为你的个人品味和喜好是最重要的，尽管通常情况下你要么按照最具体到最不具体的顺序排列，要么相反(我更喜欢后者)。

在每个组中，我通常只是按字母顺序排列。

3.包含顺序重要吗?

如果头文件是自包含的，那么从技术上讲，包含顺序对编译结果应该没有任何影响。

也就是说，除非您对代码有特定的设计选择(有问题吗?)，比如没有自动包含的必要宏定义。在这种情况下，您应该重新考虑您的程序设计，尽管它当然可能非常适合您。

这不是主观的。确保你的头文件不依赖于以特定顺序被#包含。可以肯定的是，不管你以什么顺序包含STL或Boost头文件。