前言

很多问题，你以为你学会了，其实你学废了；只有在项目实践中，你才能发现自己Too young ，Too simple

Talk is cheap，show me the code

我们使用一个代码实例，来演示头文件包含问题。

main.c:#include <stdio.h>#include "a.h"int main(){  funcA();  printf("hello world");  return 0;}a.h:#include "b.h"void funcA();b.h:#include "c.h"void funcB();c.h:#include "a.h"void funcC();

其中包含5个文件，一个c文件，3个头文件，一个makefile文件，main.c使用了头文件A声明的函数funcA，头文件A中依赖头文件B，头文件B依赖头文件C，头文件C依赖头文件A，因此头文件A->头文件B->头文件C->头文件A，造成了循环依赖。

我们使用make命令编译一下，看看会出现什么情况

                 from b.h:1,                 from a.h:1,                 ...                 from b.h:1,                 from a.h:1,                 from main.c:2:a.h:1:15: error: #include nested too deeply    1 | #include "b.h"      |               ^make: *** [Makefile:5: main.o] Error 1[saltape@ubuntu ~/project/C]$

毫无悬念的出现了编译错误，原因是头文件嵌套太深。这种错误比较小白，当然真实的项目中是可能出现这样的问题的，只不过由于各种技术问题，没有出现编译报错问题，但是造成了更为严重的后果————编译时间太长。

这种问题怎么避免呢？对于小白，只写几个文件，一般是看不到这种问题的，只有在公司的项目中，文件越来越多，可能会出现问题。下面我们对于头文件包含讲解几个重要的原则；掌握了这些原则，就极大可能避免这种问题(说极大可能，是因为每个人的编码能力不同，不可能靠几个人来规避这种问题)

原则1：

使用头文件保护符

#ifndef ... #endif

头文件保护符指的是下列这一段代码或者与之功能相同的代码，其功能是防止头文件被多次包含而出错；

```#ifndef HEADER_H#define HEADER_H//coding#endif``

在头文件保护符中涉及到了4种指令：

#define：用于将一个名字设定为预处理变量，该名字通常以头文件的全大写同名确定；#ifdef: 判断一个名字是否被定义为预处理变量，如果已定义，则为True；#ifndef: 与上一个想法，未定义时为True；#endif: 结束指令，如果#ifdef或者ifndef为False，则直接跳到该指令之后的代码。

原则2：头文件应当自包含

头文件自包含意味着，编译该头文件不需要引入额外的头文件。如果引入其他的头文件才能编译通过，那么就会引入编译依赖，这就给编译时间增加了无限可能。

原则3：头文件不应该包含无用的头文件

在遵循原则2的基础上，应该去除不需要的头文件；每多一个头文件，都会导致编译时间的增加，此外，如果修改了不需要的文件，就需要重新编译该头文件。

在公司曾经遇到过“上帝头文件”，这个上帝头文件是怎么回事呢？它自身包含了所有的头文件，其他组开发人员只需要包含这一个头文件就可以了，虽然对于开发人员省力了，但是从编译角度看，它是非常不可取的，这样导致编译时间急剧增加，给后期维护增加了巨大困难。

原则4：禁止头文件循环依赖

文章开头，就是拿头文件依赖举例子，直接导致编译不过，虽然现实中技术上也能让编译通过，不过我劝你不要这样做，编译时间增加是肯定的，后期不知道什么时候会直接导致项目挂掉。

原则5：头文件功能应该单一

我们知道，C语言中有类型、宏声明，也有函数声明，这一原则建议头文件将类型、宏定义和函数定义分开。曾经在公司做组件解耦的工作，因为文件需要一个宏，包含了十几个文件。这样的使用，显然是不合理的。

原则6:对外接口与对内接口分开

在公司，大都是多个组合作开发，组与组之间有接口调用，我们对外提供接口时，避免与内部接口放到一起；一方面防止误用，另一方面，防止接口的更新导致对外调用失败。

散步引发的思考

刚才在路上散步，突然想起在公司做组件解耦的工作时，曾经使用过一款头文件依赖扫描工具，可以检测出头文件循环依赖等问题，当时觉得挺牛逼，果然还是大公司人才济济。

现在想想，我有一个不成熟的想法，也可以实现类似的功能，如果感兴趣的小伙伴可以实现一下，如果实现不了，也可以联系我哦~~~

头文件依赖扫描算法

扫描每个路径下的头文件对每个头文件抽取它所包含的头文件，保存下来，形成表格

其中第一列表示扫描的头文件，第2,3列表示它依赖的头文件

根据上一步扫描的表格，可以形成头文件依赖有向图

我们要扫描这个有向图，将其中的环扫描出来就能得到文件循环依赖。

要实现以上算法，需要用到数据结构中图的遍历、有向图遍历、并查集(union find)，建议使用python实现

欢迎感兴趣的小伙伴扫一扫上面的二维码，私信我哦