C语⾔中头⽂件包含的处理原则
很多事不深⼊以为⾃⼰懂了，但真正⽤到项⽬上，才发现了问题。曾以为⾃⼰写C语⾔已经轻车熟路了，特别是对软件⽂件的⼯程管理上，因为⼼⾥对⾃⼰的代码编写风格还是有⾃信的。(毕竟刚毕业时⽼⼤对我最初的训练就是编码格式的规范化处理)
曾以为，⼀个.c⽂件对应⼀个.h⽂件,.c⽂件只包含它⾃⾝的.h⽂件就好，若.c⽂件中⽤到其他⽂件中的内容，则.h⽂件把⽤到的头⽂件包含进来就可以了。⾃⼰貌似⼀直秉承这个理念在进⾏代码编写（好可怕）。⼯程⽂件数量⼩时，这种理念貌似看不出问题，但随着⼯程⽂件数量越来越多，我发现⾃⼰这种思路有了弊端：头⽂件互相包含，导致编译时⾃以为有些宏变量声明了，它就能起作⽤，但实际测试发现这种⽅式编码后，有些声明的宏没能起到作⽤。(.h⽂件我采⽤了避免重复包含的extern"C"的写法)
经过领导及同事的指正，⾃⼰才明⽩原有的代码编写习惯不正确。应该秉承.c⽂件对应的.h⽂件只包含头⽂件⾥⽤到的其它⽂件的头⽂件，任何⾮必须的.h⽂件不要包含；⽽.c⽂件⾥⾯要包含⽤到的所有.h⽂件。这样写即使存在.c⽂件内头⽂件重复包含也不伤⼤雅。
语⾔描述有时太抽象，还是符号举例说明下：假如有两个.c⽂件分别为A.c和B.c，⾃然它们都有各⾃的A.h和B.h⽂件。
原有的思路：A.c⾥⾯只有⼀个#include "A.h",⽽A.h所包含的就是⼀⼤堆如B.h,C.h,⽂件，因为A.c⽂件⾥⾯要⽤到B.h,C.h,D.h ⾥⾯的内容。如图⼀所⽰
新思路：A.h⾥⾯只包含A.h所写内容要⽤到的.h⽂件，很多时候A.h⾥⾯⽆需任何.h⽂件.⽽在A.c⽂件内就要写成  #include "B.h"
#include "C.h"      #include "D.h"。⽽且两个⽂件的.c⽂件在头⽂件包含上可以互相包含。如图⼆所⽰
图⼀
图⼆
项⽬中遇到的这个头⽂件包含问题导致我重新搜索资料进⾏该问题的深⼊了解，故下⽂是通过⽹络资源的搜查及加上⾃⼰对它的理解，进⾏了相关内容的整理，希望对感兴趣的⼩伙伴有所帮助。
背景
对于C语⾔来说，头⽂件的设计体现了⼤部分的系统设计。 不合理的头⽂件布局是编译时间过长的根因，不合理的头⽂件实际上不合理的设计。
依赖
特指编译依赖。若x.h包含了y.h，则称作x依赖y。依赖关系会进⾏传导，如x.h包含y.h，⽽y.h⼜包含了
z.h，则x通过y依赖了z。依赖将导致编译时间的上升。虽然依赖是不可避免的，也是必须的，但是不良的设计会导致整个系统的依赖关系⽆⽐复杂，使得任意⼀个⽂件的修改都要重新编译整个系统，导致编译时间巨幅上升。
在⼀个设计良好的系统中， 修改⼀个⽂件，只需要重新编译数个，甚⾄是⼀个⽂件。
某产品曾经做过⼀个实验，把所有函数的实现通过⼯具注释掉，其编译时间只减少了不到10%，究其原因，在于A包含B， B包含C， C包含D，最终⼏乎每⼀个源⽂件都包含了项⽬组所有的头⽂件，从⽽导致绝⼤部分编译时间都花在解析头⽂件上。
某产品更有⼀个“优秀实践”，⽤于将.c⽂件通过⼯具合并成⼀个⽐较⼤的.c⽂件，从⽽⼤幅度提⾼编译效率。其根本原因还是在于通过合并.c⽂件减少了头⽂件解析次数。但是，这样的“优秀实践”是对合理划分.c⽂件的⼀种破坏。
⼤部分产品修改⼀处代码，都得需要编译整个⼯程，对于TDD之类的实践，要求对于模块级别的编译时间控制在秒级，即使使⽤分布式编译也难以实现，最终仍然需要合理的划分头⽂件、以及头⽂件之间的包含关系， 从根本上降低编译时间。
《google C++ Style Guide》 1.2 头⽂件依赖 章节也给出了类似的阐述：
若包含了头⽂件aa.h，则就引⼊了新的依赖：
⼀旦aa.h被修改，任何直接和间接包含aa.h代码都会被重新编译。如果aa.h⼜包含了其他头⽂件如bb.h，那么bb.h的任何改变都将导致所有包含了aa.h的代码被重新编译，在敏捷开发⽅式下，代码会被频繁构建，漫长的编译时间将极⼤的阻碍频繁构建。因此，我们倾向于减少包含头⽂件，尤其是在头⽂件中包含头⽂件，以控制改动代码后的编译时间。
合理的头⽂件划分体现了系统设计的思想，但是从编程规范的⾓度看，仍然有⼀些通⽤的⽅法，⽤来合理规划头⽂件。本章节介绍的⼀些⽅法，对于合理规划头⽂件会有⼀定的帮助。
原则1.1：头⽂件中适合放置接⼝的声明，不适合放置实现。
说明： 头⽂件是模块（ Module）或单元（ Unit）的对外接⼝。头⽂件中应放置对外部的声明，如对外提供的函数声明、宏定义、类型定义等。
内部使⽤的函数（相当于类的私有⽅法）声明不应放在头⽂件中。
内部使⽤的宏、枚举、结构定义不应放⼊头⽂件中。
变量定义不应放在头⽂件中，应放在.c⽂件中。
变量的声明尽量不要放在头⽂件中，亦即尽量不要使⽤全局变量作为接⼝ 。变量是模块或单元的内部实现细节，不应通过在头⽂件中声明的⽅式直接暴露给外部，应通过函数接⼝的⽅式进⾏对外暴露。 即使必须使⽤全局变量，也只应当在.c中定义全局变量，在.h中仅声明变量为全局的。
延伸阅读材料： 《 C语⾔接⼝与实现》 （ David R. Hanson 著 傅蓉 周鹏 张昆琪 权威 译 机械⼯业出版社 2004年1⽉） （英⽂版：“C Interfaces and Implementations”）
原则1.2：头⽂件应当职责单⼀。
说明：头⽂件过于复杂，依赖过于复杂是导致编译时间过长的主要原因。 很多现有代码中头⽂件过⼤，职责过多， 再加上循环依赖的问题，可能导致为了在.c中使⽤⼀个宏，⽽包含⼗⼏个头⽂件。
某个头⽂件不但定义了基本数据类型WORD，还包含了stdio.h syslib.h等等不常⽤的头⽂件。如果⼯程中有10000个源⽂件，⽽其中100个源⽂件使⽤了stdio.h的printf，由于上述头⽂件的职责过于庞⼤，⽽WORD⼜是每⼀个⽂件必须包含的，从⽽导致stdio.h/syslib.h等可能被不必要的展开了9900次，⼤⼤增加了⼯程的编译时间。
原则1.3：头⽂件应向稳定的⽅向包含。
说明： 头⽂件的包含关系是⼀种依赖，⼀般来说，应当让不稳定的模块依赖稳定的模块，从⽽当不稳
定的模块发⽣变化时，不会影响（编译）稳定的模块。
就我们的产品来说，依赖的⽅向应该是： 产品依赖于平台，平台依赖于标准库。 某产品线平台的代码中已经包含了产品的头⽂件，导致平台⽆法单独编译、发布和测试， 是⼀个⾮常糟糕的反例。
除了不稳定的模块依赖于稳定的模块外，更好的⽅式是两个模块共同依赖于接⼝，这样任何⼀个模块的内部实现更改都不需要重新编译另外⼀个模块。在这⾥，我们假设接⼝本⾝是最稳定的。
延伸阅读材料： 编者推荐开发⼈员使⽤“依赖倒置”原则，即由使⽤者制定接⼝，服务提供者实现接⼝，更具体的描述可以参见《 敏捷软件开发：原则、模式与实践》 （ Robert C.Martin 著 邓辉 译 清华⼤学出版社2003年9⽉） 的第⼆部分“敏捷设计”章节。
规则1.1：每⼀个.c⽂件应有⼀个同名.h⽂件，⽤于声明需要对外公开的接⼝。
说明： 如果⼀个.c⽂件不需要对外公布任何接⼝，则其就不应当存在，除⾮它是程序的⼊⼝，如main函数所在的⽂件。
现有某些产品中，习惯⼀个.c⽂件对应两个头⽂件，⼀个⽤于存放对外公开的接⼝，⼀个⽤于存放内部需要⽤到的定义、声明等，以控制.c ⽂件的代码⾏数。编者不提倡这种风格。这种风格的根源在于源⽂件过⼤，应⾸先考虑拆分.c⽂件，使之不⾄于太⼤。另外，⼀旦把私有定义、声明放到独⽴的头
⽂件中，就⽆法从技术上避免别⼈include之，难以保证这些定义最后真的只是私有的。
本规则反过来并不⼀定成⽴。有些特别简单的头⽂件，如命令ID定义头⽂件，不需要有对应的.c存在 。
⽰例：对于如下场景，如在⼀个.c中存在函数调⽤关系：
void foo()
{
bar();
}
void bar()
{
Do something;
c语言如何去学}
必须在foo之前声明bar，否则会导致编译错误。
这⼀类的函数声明，应当在.c的头部声明，并声明为static的，如下：
static void bar();
void foo()
{
bar();
}
void bar()
{
Do something;
规则1.2：禁⽌头⽂件循环依赖。
说明： 头⽂件循环依赖，指a.h包含b.h， b.h包含c.h， c.h包含a.h之类导致任何⼀个头⽂件修改，都导致所有包含了a.h/b.h/c.h的代码全部重新编译⼀遍。⽽如果是单向依赖，如a.h包含b.h， b.h包含c.h，⽽c.h不包含任何头⽂件，则修改a.h不会导致包含了b.h/c.h的源代码重新编译。
规则1.3：.c/.h⽂件禁⽌包含⽤不到的头⽂件。
说明： 很多系统中头⽂件包含关系复杂，开发⼈员为了省事起见，可能不会去⼀⼀钻研，直接包含⼀切想到的头⽂件，甚⾄有些产品⼲脆发布了⼀个god.h，其中包含了所有头⽂件，然后发布给各个项⽬组使⽤，这种只图⼀时省事的做法，导致整个系统的编译时间进⼀步恶化，并对后来⼈的维护造成了巨⼤的⿇烦。
规则1.4：头⽂件应当⾃包含。
说明： 简单的说，⾃包含就是任意⼀个头⽂件均可独⽴编译。 如果⼀个头⽂件包含某个头⽂件，还要包含另外⼀个头⽂件才能⼯作的话，就会增加交流障碍，给这个头⽂件的⽤户增添不必要的负担 。
⽰例：
如果a.h不是⾃包含的，需要包含b.h才能编译，会带来的危害：
每个使⽤a.h头⽂件的.c⽂件，为了让引⼊的a.h的内容编译通过，都要包含额外的头⽂件b.h。
额外的头⽂件b.h必须在a.h之前进⾏包含，这在包含顺序上产⽣了依赖。
注意：该规则需要与“ .c/.h⽂件禁⽌包含⽤不到的头⽂件”规则⼀起使⽤，不能为了让a.h⾃包含，⽽在a.h中包含不必要的头⽂件。 a.h要刚刚可以⾃包含，不能在a.h中多包含任何满⾜⾃包含之外的其他头⽂件。
规则1.5：总是编写内部#include保护符（ #define 保护）。
说明：多次包含⼀个头⽂件可以通过认真的设计来避免。如果不能做到这⼀点，就需要采取阻⽌头⽂件内容被包含多于⼀次的机制。
通常的⼿段是为每个⽂件配置⼀个宏，当头⽂件第⼀次被包含时就定义这个宏，并在头⽂件被再次包含时使⽤它以排除⽂件内容。
所有头⽂件都应当使⽤#define 防⽌头⽂件被多重包含，命名格式为FILENAME_H，为了保证唯⼀性，更好的命名是
PROJECTNAME_PATH_FILENAME_H。
注：没有在宏最前⾯加上““，即使⽤FILENAME_H代替_FILENAME_H，是因为⼀般以”“和”_“开头的标
识符为系统保留或者标准库使⽤，在有些静态检查⼯具中，若全局可见的标识符以”_”开头会给出告警。
定义包含保护符时，应该遵守如下规则：
1）保护符使⽤唯⼀名称；
2）不要在受保护部分的前后放置代码或者注释。
⽰例：假定VOS⼯程的timer模块的timer.h，其⽬录为VOS/include/timer/timer.h，应按如下⽅式保护：
#ifndef VOS_INCLUDE_TIMER_TIMER_H
#define VOS_INCLUDE_TIMER_TIMER_H
...
#endif
也可以使⽤如下简单⽅式保护:
#ifndef TIMER_H
#define TIMER_H
..
#endif
例外情况：头⽂件的版权声明部分以及头⽂件的整体注释部分（如阐述此头⽂件的开发背景、使⽤注意事项等）可以放在保护符(#ifndef XX_H)前⾯。
规则1.6：禁⽌在头⽂件中定义变量。
说明：在头⽂件中定义变量，将会由于头⽂件被其他.c⽂件包含⽽导致变量重复定义。
规则1.7：只能通过包含头⽂件的⽅式使⽤其他.c提供的接⼝，禁⽌在.c中通过extern的⽅式使⽤外部函数接⼝、变量 。
说明：若a.c使⽤了b.c定义的foo()函数，则应当在b.h中声明extern int foo(int input)；并在a.c中通过#include 来使⽤foo。禁⽌通过在a.c中直接写extern int foo(int input)；来使⽤foo，后⾯这种写法容易在foo改变时可能导致声明和定义不⼀致 。
规则1.8：禁⽌在extern “C”中包含头⽂件。
说明：在extern “C”中包含头⽂件， 会导致extern “C”嵌套， Visual Studio对extern “C”嵌套层次有限制，嵌套层次太多会编译错误。
在extern “C”中包含头⽂件，可能会导致被包含头⽂件的原有意图遭到破坏。例如，存在a.h和b.h两个头⽂件：
使⽤C++预处理器展开b.h，将会得到
extern "C"
{
void foo(int);
void b();
}
按照a.h作者的本意，函数foo是⼀个C++⾃由函数，其链接规范为”C++”。但在b.h中，由于#include “a.h”被放到了extern “C” { }的内部，函数foo的链接规范被不正确地更改了。
⽰例： 错误的使⽤⽅式：
extern “C”
{
#include “xxx.h”
...
}
正确的使⽤⽅式：
#include “xxx.h”

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。