测控研究生编程规范.doc

北化测控研究生C语言编程规范 范围： 本规范适用于北化测控研究所内部使用C语言编写的程序，其它语言也可类比使用。本规范自修订完成后开始生效，以后新编写的和修改的代码应遵守本规范。 简介： 针对实验室同仁编写程序的不规范性、风格各异，给后续学习带来很大困难。根据实验室于涛老师的要求，制定了本实验室内部的编写C语言程序的基本原则、规则和建议。从代码的清晰、简洁、可测试、安全、程序效率、可移植各个方面对C语言编程作出了具体指导。在制定过程中主要参考了《华为技术有限公司c语言编程规范》和《Google C++ 编程规范》。 第一章 规范制定说明 1.1 前言 为提高产品代码质量，指导实验室同学编写出简洁、可维护、可靠、可测试、高效、可移植的代码，编程规范修订工作组分析、总结了各种典型编码问题，并参考了业界编程规范近年来的成果，在对其它编程规范进行了梳理、优化、刷新，编写了本规范。 1.2 代码总体原则 清晰第一 清晰性是易于维护、易于重构的程序必需具备的特征。代码首先是给人读的，好的代码应当可以像文章一样发声朗诵出来。 目前软件维护期成本占整个生命周期成本的40%~90%。根据业界经验，维护期变更代码的成本，小型系统是开发期的5倍，大型系统（100万行代码以上）可以达到100倍。业界的调查指出，开发组平均大约一半的人力用于弥补过去的错误，而不是添加新的功能来帮助公司提高竞争力。 “程序必须为阅读它的人而编写，只是顺便用于机器执行。”——Harold Abelson “编写程序应该以人为本，计算机第二。”——Steve McConnell 简洁为美 简洁就是易于理解并且易于实现。代码越长越难以看懂，也就越容易在修改时引入错误。写的代码越多，意味着出错的地方越多，也就意味着代码的可靠性越低。因此，我们提倡大家通过编写简洁明了的代码来提升代码可靠性。废弃的代码要及时清除，重复代码应该尽可能提炼成函数。 选择合适的风格，与代码原有风格保持一致 产品所有人共同分享同一种风格所带来的好处，远远超出为了统一而付出的代价。在公司已有编码规范的指导下，审慎地编排代码以使代码尽可能清晰，是一项非常重要的技能。 1.3 术语规范 原则：编程时必须坚持的指导思想。 规则：编程时强制必须遵守的约定。 建议：编程时必须加以考虑的约定。 说明：对此原则/规则/建议进行必要的解释。 第二章 头文件 对于C语言来说，头文件的设计体现了大部分的系统设计。不合理的头文件布局是编译时间过长的根因，不合理的头文件实际上既是不合理的设计。合理的头文件划分体现了系统设计的思想，但是从编程规范的角度看，仍然有一些通用的方法，用来合理规划头文件。下面介绍的一些方法，对于合理规划头文件会有一定的帮助。 原则2.1 头文件中适合放置接口的声明，不适合放置实现 头文件是模块（Module）或单元（Unit）的对外接口。头文件中应放置对外部的声明，如对外提供的函数声明、宏定义、类型定义等。 内部使用的函数（相当于类的私有方法）声明不应放在头文件中。 内部使用的宏、枚举、结构定义不应放入头文件中。 变量定义不应放在头文件中，应放在.c文件中。 变量的声明尽量不要放在头文件中，亦即尽量不要使用全局变量作为接口。变量是模块或单元的内部实现细节，不应通过在头文件中声明的方式直接暴露给外部，应通过函数接口的方式进行对外暴露。 即使必须使用全局变量，也只应当在.c中定义全局变量，在.h中仅声明变量为全局的。 原则2.2 头文件应当职责单一 头文件过于复杂，依赖过于复杂是导致编译时间过长的主要原因。很多现有代码中头文件过大，职责过多，再加上循环依赖的问题，可能导致为了在.c中使用一个宏，而包含十几个头文件。 原则2.3 头文件应向稳定的方向包含 头文件的包含关系是一种依赖，一般来说，应当让不稳定的模块依赖稳定的模块，从而当不稳定的模块发生变化时，不会影响（编译）稳定的模块。 规则1.1 禁止头文件循环依赖 规则1.2 .c/.h文件禁止包含用不到的头文件 规则1.3 头文件应当自包含 简单的说，自包含就是任意一个头文件均可独立编译。 规则1.4 总是编写内部#include保护符（#define 保护） 多次包含一个头文件可以通过认真的设计来避免。如果不能做到这一点，就需要采取阻止头文件内容被包含多于一次的机制。 规则1.5 禁止在头文件中定义变量 在头文件中定义变量，将会由于头文件被其他.c文件包含而导致变量重复定义。 规则1.6 只能通过包含头文件的方式使用其他.c提供的接口，禁止在.c中通过extern的方式使用外部函数接口、变量。 建议1.1 一个模块通常包含多个.c文件，建议放在同一个目录下，目录名即为模块名。为方便外部使用者，建