C++ include 顺序

我不认同google style。我倾向于链接2 里面的的解释。

我倾向的风格： local to global 

1. cpp 对应的h 文件

2. 同一个模块的h 文件

3. 其他模块的 h 文件（内部，或者外部，如Qt，Eigen)

4. 系统级别的 C++ h 文件

5. 系统级别的 C h 文件

 

Google Style： global to local 

1. cpp 对应的h 文件

2. C 语言头文件

3. C++ h 文件

4. 其他组件（lib）的h文件

5. 本模块的 h 文件

原因：

1，虽然说 C++ 头文件都会对应的超集包含 C 头文件，我们一般是不需要写 C 头文件的。为什么要写C的代码呢？既然C++都封装好了，那就用C++。如果有些功能还不如C的好，把C头文件放在 后面也没什么问题 。要是因为C++ 头文件在前、C头文件在后导致了什么问题。我相信，这就应该可以给C++ 编译器厂商，或者C++标准委员会提issue了。如果你想要使用使用 C  header，那么，一定是基于非常强的理由，这个理由，甚至

2，为什么 业务模块头文件 应该在 系统级别 头文件的前面？开发者水平各异，不能保证有人干出把 更高优先级的macro干掉，然后导致整个build错误的问题。我们曾经遇到真有人这么干过，即使我自己，我也并不敢保证一定不会把别人的 macro 干掉，所以，我自己写macro的时候，尽量用上前缀，尽量足够长。也尽量避免使用macro。但是，如果把别人的 header 设定操作放在后面，则可以完全避免这种情形。如果因为自己的macro 被 更高级的 模块 覆盖了，而且，还没有认真看build warning，那只能自己咽下这苦果了。

3，基于2同样的原因，我们不能改动其他模块的 头文件内部设定（主要是macro）。

  之前，我们项目用到一个lib， 会依赖于windows.h 头文件，导致 自己module 头文件 不能比它们 出现的更早。我对于这样的lib都持有怀疑态度。连模块依赖最小化都没有做好，我怎么能相信会把里面代码写好。既然它做了这个，天知道这个lib还做了什么？我一向以为，我们是不应该去改动任何语言级别的设定的。不要妄图修改C/C++的头文件。但是啊，总有人就是想要这么做。所以，我就恶意揣测，还是有人会修改系统级，或者比它低层次的模块的头文件，但是，把低层次的头文件放在最后，这是一种激进策略，尽早让高层模块的错误暴露出来。

    P.S.  我要好好整理笔记了。一堆放了几年的东西。

  

1. https://google.github.io/styleguide/cppguide.html#Names_and_Order_of_Includes
2. https://stackoverflow.com/questions/2762568/c-c-include-header-file-order