在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行将断言一个宏重定义错误。

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

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

我不认为有一个推荐的顺序，只要它编译!令人恼火的是，有些头文件需要先包含其他头文件……这是头文件本身的问题，而不是包含顺序的问题。

我个人倾向于从局部到全局，每个小节按字母顺序排列，即:

H文件对应此CPP文件(如适用) 来自同一个组件的头文件， 来自其他组件的头文件， 系统头文件。

我的理由是1。它应该证明每个头文件(其中有cpp)可以在没有先决条件的情况下被#包含(terminus technicus:头文件是“自包含的”)。剩下的似乎就从这里顺理成章地展开了。

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

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

我还遵循以下准则:

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

换句话说:

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

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

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

我建议:

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

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

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

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

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

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