C/C++ 编程规范--头文件

一 ：头文件

• 对于C语言来说，头文件的设计体现了大部分的系统设计。

• 不合理的头文件布局是编译时间过长的根因（编译依赖消耗编译器90%以上的时间），降低头文件的依赖是总体原则，不合理的头文件实际上是不合理的设计。

• 合理的头文件划分体现了系统设计的思想，但是从编程规范的角度看，仍然有一些通用的方法，用来合理规划头文件。本章节介绍的一些方法，对于合理规划头文件会有一定的帮助。

（1）讨论：如下头文件有什么问题？

#include<VXWORKS.H> 

#include<KERNELLIB.H> 

#include<SEMLIB.H> 

#include<INTLIB.H> 

#include<TASKLIB.H> 

#include<MSGQLIB.H> 

#include<STDARG.H> 

#include<FIOLIB.H> 

#include<STDIO.H> 

#include<STDLIB.H> 

#include<CTYPE.H> 

#include<STRING.H> 

#include<ERRNOLIB.H> 

#include<TIMERS.H> 

#include<MEMLIB.H> 

#include<TIME.H> 

#include<WDLIB.H> 

#include<SYSLIB.H> 

#include<TASKHOOKLIB.H> 

#include<REBOOTLIB.H>

问题：

  a) 头文件过于复杂，依赖过于复杂是导致编译时间过长的主要原因。很多现有代码中头文件过大，职责过多，再加上循环依赖的问题，可能导致为了在.c中使用一个宏，而包含十几个头文件。

  b) 这个头文件不但定义了基本数据类型WORD，还包含了stdio.h syslib.h等等不常用的头文件。如果工程中有10000个源文件，而其中100个源文件使用了stdio.h的printf，由于上述头文件的职责过于庞大，而WORD又是每一个文件必须包含的，从而导致stdio.h/syslib.h等可能被不必要的展开了9900次，大大增加了工程的编译时间。

（2）头文件原则：

  原则一：头文件中适合放置接口的声明，不适合放置实现
  原则二：头文件应当职责单一
  原则三：头文件应向稳定的方向包含

（3）头文件规则：

 规则一：每一个.c文件应有一个同名.h文件，用于声明需要对外公开的接口
 规则二：禁止头文件循环依赖
 规则三：.c/.h文件禁止包含用不到的头文件
 规则四：总是编写内部#include保护符（#define 保护）
 规则五：禁止在头文件中定义变量
 规则六：只能通过包含头文件的方式使用其他.c提供的接口，禁止在.c中通过extern的方式使用外部函数接口、变量