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

1. 检查自制力

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

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

gcc headerfile.h -fsyntax-only

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

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

2. 可读性

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

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

3.包含顺序重要吗?

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

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

首先包含与.cpp…换句话说，source1.cpp应该在包含任何其他内容之前包含source1.h。我能想到的唯一例外是在使用带有预编译头的MSVC时，在这种情况下，你被迫在其他任何东西之前包含stdafx.h。

理由:在任何其他文件之前包含source1.h可以确保它可以独立于它的依赖项。如果source1.h在以后有了依赖项，编译器会立即提醒您向source1.h添加所需的前向声明。这反过来又确保了头文件可以由它们的依赖项以任何顺序包含。

例子:

source1.h

class Class1 {
    Class2 c2;    // a dependency which has not been forward declared
};

source1.cpp

#include "source1.h"    // now compiler will alert you saying that Class2 is undefined
                    // so you can forward declare Class2 within source1.h
...

MSVC用户:我强烈建议使用预编译的头文件。因此，将标准头文件(以及其他永远不会改变的头文件)的所有#include指令移到stdafx.h。

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

我遵循两个简单的规则来避免绝大多数问题:

所有的头文件(实际上包括任何源文件)都应该包含它们所需要的内容。他们不应该依赖于他们的用户，包括东西。 作为补充，所有的头文件都应该包含保护，这样它们就不会因为过于雄心勃勃地应用上述规则1而被多次包含。

我还遵循以下准则:

首先使用分隔线包含系统头文件(stdio.h等)。 将它们进行逻辑分组。

换句话说:

#include <stdio.h>
#include <string.h>

#include "btree.h"
#include "collect_hash.h"
#include "collect_arraylist.h"
#include "globals.h"

虽然，作为指导方针，这是主观的事情。另一方面，我严格执行规则，甚至提供'包装'头文件包含保护和分组包含，如果一些讨厌的第三方开发人员不同意我的愿景:-)

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

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

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

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

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

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

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

在C/ c++世界中，这是一个很难回答的问题，因为有太多超出标准的元素。

我认为头文件的顺序不是一个严重的问题，只要它编译，就像squelart说的。

我的想法是:如果所有这些标题中的符号没有冲突，任何顺序都是OK的，并且标题依赖问题可以在以后通过在有缺陷的.h中添加#include行来修复。

真正的麻烦出现在某些头文件根据上面的头文件改变其操作(通过检查#if条件)时。

例如，在VS2005的stddef.h中，有:

#ifdef  _WIN64
#define offsetof(s,m)   (size_t)( (ptrdiff_t)&(((s *)0)->m) )
#else
#define offsetof(s,m)   (size_t)&(((s *)0)->m)
#endif

现在的问题是:如果我有一个自定义头文件("custom.h")，需要与许多编译器一起使用，包括一些在系统头文件中不提供偏移量的旧编译器，我应该在我的头文件中写道:

#ifndef offsetof
#define offsetof(s,m)   (size_t)&(((s *)0)->m)
#endif

并且一定要告诉用户在所有系统头文件之后#include "custom.h"，否则，stddef.h中的offset行将断言一个宏重定义错误。

我们祈祷在我们的职业生涯中不再遇到这种情况。