Ｃ语言编码规范
目录
4.1 const 与#define的比较（2条规则）... 13
1.文件结构（4条规则＋6条建议）
C程序文件通常 分为两类文件：
一类文件用于保存程序的声明（declaration），称为头文件。头文件以“.h”为后缀。
另一类文件用于保存程序的实现（implementation），称为定义（definition）文件。定义文件以“.c”为后缀。对于简单的C语言程序，一般在把头文件和程序定 义文件放在一起，只有一个.c定义文件即可。而对于复杂的程序，则多采用头文件包含的形式并通过多个定义文件实现。
1.1 版权和版本的声明
版权和版本的 声明一般应该位于头文件和定义文件的开头（参见示例1-1），主要内容包括：
(1) 版权信息；
(2) 文件名称、文件标识、摘要；
(3) 当前版本号、作者/修改者、修改日期、修改描述等；
(4) 版本历史信息、原作者、完成日期等。
/*
* Copyright(c) 2004,北大青鸟培训中心
* All rightsreserved.
*
* 文件名称：filename.h
* 文件标识：根据软件工程设置
* 摘要：简要描述本文件的作用和内容等
*/
//下面其它的声明代码
…
//下面是原作者、版本、完成、日期和当 前版本的信息
/* 当前版本：1.0.1
* 作者：修改者名字，修改日期：2005年4月5日
* 修改的地方描述：
*/
/*
* 取代版本：1.0.0
* 原作者：原作者名字，完成日期：2004年12月31日
*/
示例1-1 版权和版本的声明
版本标识：采用<主版本号>.<次版本号>.<修订号>来命名自己产品的编号。一般这样约定，如果
次版本号是偶数（如0、2、4等），代表正式版本，如 果次版本号是奇数(如1、3、5等)，代表开发过程中的测试版本。修订号则相当于Build号，用来标识一些小的改动。
1.2 头文件的结构
头 文件由三部分内容组成：
(1) 文件开头处的版权和版本声明（参见示例1-1）；
(2) 预处理块；
(3) 声明函数原型和声明数据结构或变量等。
假设头文件名称为filename.h，头文件的结构参见示例1-2。
/*
* Copyright(c) 2004,北大青鸟培训中心
* All rightsreserved.
*
* 文件名称：filename.h
* 文件标识：根据软件工程设置
* 摘要：简要描述本文件的作用和内容等
*/
#include<stdio.h>
#include<stdlib.h>
#include<graphics.h> // 引用头文件
structstudentstruct
{
int no;
char name[20];
char sex;
float score;
};
voidGetValue()
{
}
voidSetValue(int no)
{
}
//后面同示例 1-1。
示 例1-2 C头文件结构
1.3 定义文件的结构
定 义文件有三部分内容：
（1） 定义文件开头处的版权和版本声明（参见示例1-1）;
（2） 对一些头文 件的引用;
（3） 程序的实现体（包括数据和代码）。
假设定义文件的名称为filename.c，定义文件的结构参见示例1-3
/* 版权和版本声明见示例1-1，此处省略。*/
#inlcude“filename.h”
#ifndefGRAPHICS_H // 防止graphics.h被重复引用
#defineGRAPHICS_H
/* 函数的实现体*/
voidGetValue()
{
…
}
/* 函数的实现体*/
voidSetValue(int no)
{
…
}
void main（）
{
…
｝
示例1-3 C定义文件的结构
1.4头文件和定义文件使用（4条规则＋6条建议）
【规则1-2-1】在复杂的工程文件中，为了防止头文件被重复引用，应使用ifndef/define/endif 结构产生预处理块。
【规则1-2-2】用#include<filename.h> 格式来引用标准库的头文件（编译器将从标准 库目录开始搜索）。
【规则1-2-3】用#include “filename.h” 格式来引用非标准库的头文件（编译器将从用户的工作目 录开始搜索）。
【规则1-2-4】只引用必需的头文件，不要为了防止忘记包含头文件而在每个文件开始添加很多的头文件。
【建议1-2-1】不要在头文件中定义常量或变量，注意头文件只是用来声明。
【建 议1-2-2】不提倡使用全局变量，尽量不要在头文件中出现像“extern int width；” 这类声明。
【建议1-2-3】将非系统的函数库放在一个单独的目录下引用。
【建议1-2-4】头文件应按功能组织在一起，即对单独子系统的声明应放在单独的头文件中。 此外，当代码从一个平台移植到另一个平台时有可能发生更改的声明应位于单独的头文件中，并进行相应的注释。
【建议1-2-5】避免使用与函数库中专用头文件名相同的头文件名。语句 #include "math.h" 如果在当前目录中找不到所期望文件 的话，会包括标准库 math 头文件。
【建议1-2-6】包含头 文件时一般不使用绝对路径名。
2.程序版式（35条规则＋2条建议）
2.1 空行（4条规则）
空行起着分隔程序段落的作用，空行得体将使程序的布局更加清晰。空行不会浪费内存，所以不要舍不得用空行。
【规则2-1-1】在函数内部局部变量定义结束之后处理语句之前要加空行。
【规则2-1-2】在每个函数定义结束之后都要加空行。参见示例2-1（a）。
【规 则2-1-3】函数返回语句和其他语句之间使用空行分开。
【规则2-1-4】在一个函数体内，逻辑上密切相关的语句之间不加空行，其它地方应加空行分 隔。参见示例2-1（b）。
// 空行
voidFunction1( )
{
…
}
// 空行
voidFunction2( )
{
…
}
// 空行
voidFunction3( )
{
…
}
// 空行
while(condition )
{
statement1;
// 空行
if ( condition)
{
statement2;
}
else
{
statement3;
}
// 空行
statement4;
}
示 例2-1(a) 函数之间的空行 示例2-1(b) 函数内部的空行
2.2 代 码行（5条规则＋1条建议）
【规则2-2-1】一行代码只做一件事情，如只定义一个变量，或只写一条语句。这样的代码容 易阅读，并且方便写注释。
【规则2-2-2】if、for、while、do 等语句自占一行，执行语句不得紧跟其后。不论 执行语句有多少都要加{}表 明是一个语句块。
【规则2-2-3】一对花 括号要单独各占一行。但是在do-while、struct和union及其后有‘；’的除外，要同在一行。
例如：
do
{
…
}while(i>0);
【规则2-2-4】switch语 句中的每个case语句各占一行，当某个case语句不需要break语句最好加注释声明。
【规则2-2-5】并列的语句行应该按照字母顺序排序，如变量定义和switch中的 case语句等。
【建议2-2-1】尽可能在定义变量的同时初始化该变量（就近原则），如果变量的引用处和 其定义处相隔较远，变量的初始化很容易被忘记。如果引用了未被初始化的变量，可能会导致程序错误。本建议可以减少隐患。
例如：
intwidth=20; /* 定义并初绐化width*/
intheight=20; /* 定义并初绐化height*/
intdepth=20; /* 定义并初绐化depth*/
风格良好的代码行 风格不良的代码行
intwidth; /* 宽度*/
int height; /*高度*/
intdepth; /* 深度*/ int width, height, depth; /* 宽度高度深度*/
x=a+b;
y=c+d;
z=e+f; x=a+b;y=c+d;z=e+f;
if( width <height )
{
dosomething();
} if( width < height ) dosomething();
for(initialization; condition; update)
{
dosomething();
}
// 空行
other(); for( initialization; condition; update )
dosomething();
other();
2.3 代码行内的空格（6条规则＋1条建议）
【规则2-3-1】关键字之后要留空格。象const、case等关键字之后至少要留一个空格，否则无法辨析关键字。象if、for、while等关键字和紧跟的左括号‘（’之后应留一个空格，右括号前也对应要留一个空格，以突出关键字。例如：if( a==b )
【规则2-3-2】函数名之后不要留空格，紧跟左括号‘（’，以与关键字区别。例 如：voidcalc（void）;
【规 则2-3-3】“，”之后要留空格，如Function(x,y, z)。如果‘;’不是一行的结束符号，其后要留空格，如for(initialization; condition; update )。
【规则2-3-4】不要在单目运算符(如“!”、“~”、“++”、“--”、“&”)和其操作对象间加空格。
例 如：!foo,++i,(long)getValue
【规则2-3-5】赋值操作符、比较操作符、算术操作符、逻辑操作符、位域操作符，如“=”、“+=”、“>=”、“<=”、“+”、“*”、“%”、“&&”、“||”、“<<”,“^”等 二元操作符的前后应当加空格。
【规则2-3-6】象“［］”、“.”、“->”这类操作符前后不加空格。
例 如：big.bar,pFile->bar,big[bar]
【建议2-3-1】对于表达式较长的for语句和if语句， 为了紧凑起见可以适当地去掉一些空格.
例如：for( i=0; i<10;i++ )和if( (a<=b) && (c<=d) )
风格良好的空格 风格不良空格
void Func1(intx, int y, int z); void Func1 (int x,inty,int z);
if( year >=2000 )
if( (a>=b)&& (c<=d) ) if(year>=2000)
if(a>=b&&c<=d)
for( i=0;i<10; i++ ) for(i=0;i<10;i++)
for (i = 0; i< 10; i ++)
x = a < b ?a : b; x=a<b?a:b;
int *x =&y; int * x = & y;
array[5] = 0;
a.Function();
b->Function(); array [ 5 ] = 0;
a.Function();
b ->Function();
2.4 对 齐（4条规则）
【规则2-4-1】程序的分界符‘{’和‘}’应独占 一行并且位于同一列，同时与引用它们的语句左对齐。【规则2-4-2】水平缩进每次使用四个空格即可(定义一个tab键为四个空格。有的要求缩进两个空格)。
【规则2-4-3】同属于一个语句块的代码对齐。
【规则2-4-4】{ }之内的代码块在‘{’右边一个tab键处左对齐。
风格良好的对齐 风格不良的对齐
voidFunction(int x)
{
program code
} void Function(int x){
program code
}
if( condition)
{
program code
}
else
{
program code
} if(condition){
program code
}
else {
program code
}
for(initialization; condition; update )
{
program code
} for(initialization; condition; update){
…program code
}
while(condition )
{
program code
} while(condition){
…program code
}
如果出现嵌套的｛｝，则使用缩进对齐，如：
{
{
}
}
2.5 长行拆分（2条规则）
【规则2-5-1】代码行最大长度宜控制在70至80个字符以内。代码行不宜过长，否则不便于阅读，也不便于打印。
【规则2-5-2】长表达式要在低优先级操作符处拆分成新行，操作符放在新行之首（以便突 出操作符）。拆分出的新行要进行适当的缩进，使排版整齐，语句可读。
if((very_longer_variable1 >= very_longer_variable12 )
&&(very_longer_variable3 <= very_longer_variable14)
&&(very_longer_variable5 <= very_longer_variable16))
{
dosomething();
}
virtualCMatrix CMultiplyMatrix (CMatrix leftMatrix,
CMatrixrightMatrix);
for(very_long_initialization;
very_long_condition;
very_long_update)
{
dosomething();
}
示例2-5 长行的拆分
2.6 修饰符的位置（1条规则）
【规则2-6-1】将修饰符 * 和 ＆紧靠变量名,以免引起误解。
例如：char *name;
int *x,y; /* 此处y 不会被误解为指针*/
2.7 注释（12条规则）
C 语言的注释符为“/*… */”和“//”。注释通常用于：
（1）版本、版权声明；
（2）函数接口说明,包括参数类型和意义、函数类型和意义等；
（3）重要的数据类型声明、变量、算法、处理、段落等提示。
“//”为行注释。
【规则2-7-1】注释是对代码作用的“提示”，而不是文档。注释的频度要合适，一般要求 占程序总行数的1/5～1/4。
【规则2-7-2】边写代码边注释，修改代码同时修改相应的注释，以保证注释与代码的一致性。不再有用的注释要删除。
【规则2-7-3】注释应准确、易懂，防止注释有二义性。错误的注释不但无益反而有害。
【规则2-7-4】尽量避免在注释中使用缩写，特别是不常用的缩写。根据维护程序的对象确 定使用中文还是使用英文。
【规则2-7-5】注释的位置应与被描述代码相邻，可以放在代码的上方或右方，一般不宜放在下方。
【规则2-7-6】当代码比较长，特别是有多重嵌套时，应当在一些段落的结束处加注释，便 于阅读。
【规则2-7-7】尽量不要在语句指令中添加注释。
【规则2-7-8】注释不具备约束使用者行为的能力。
【规则2-7-9】给一行代码添加注释最好使用“//”，比较清楚。
【规则2-7-10】不要使用/**/注释掉大量代码，而要使用#if0条件编译语句
例如：
#if 0
if(debugLevel>1 )
{
...
}
#endif
【规则2-7-11】行末注释最好对齐。
【规则2-7-12】应对包 含的头文件进行行末注释。
3.标识符命名（15条规则＋1条建议）
共性规则是被大多数程序员采纳的，我们应当在遵循这些共性规则。
命名两个基本原则：
1.含义清晰，不易混淆；
2.不与其它模块、函数的命名空间相冲 突。
【规则3-1-1】标识符要清楚、准确、简单而且尽量可发音的英文名字。
例如：int returnStatus；
不要把currentValue 写成nowValue。
【规则3-1-2】标识符的长度应当符合“min-length&& max-information”（最短并包含信息最多）原则。单字符的名字也是有用的，常见的如i、j、k、m、n、x、y、z 等，它们通常可用作函数内的局部变量。
【规 则3-1-3】命名规则尽量与所采用的操作系统或开发工具的风格保持一致。
例如Windows应用程序的标识符通常采用“大小写”混排的方式，如 printStudent；而Unix 应用程序的标识符通常采用“小写加下划线”的方式，如print_student。别把这两类风 格混在一起用。
【规则3-1-4】尽量选择通用词汇并保持整个软件风格一致。
例如：使用get、read、fetch 、retrieve都能表达“取出”的意思，一旦软件采用哪一 个则应贯穿始终。
【规则3-1-5】程序中不要出现仅靠大小写区分的相似的标识符。
例如：int x, X; /* 变量x 与X 容易混淆*/
void foo(int y); /* 函数foo 与FOO容易混淆*/
void FOO(floaty);
【规则3-1-6】程序中不要出现标识符完全相同的局部变量和全局变量，尽管可能两者的作用域不同而不会发生语法错误，但会使人误解。
【规则3-1-7】变量的名字应当使用“名词”或者“形容词＋名词”。
例如： float value;
float newValue;
【规则3-1-8】用正确的反义词组命名具有互斥意义的变量或相反动作的函数等。
例如： int MinValue;
int MaxValue;
int MinValue(void);
int MaxValue(void);
【规则3-1-9】变量和参数首字母小写，其后每个英文单词的第一个字母大写，其它小写。
例 如：int recWidth;
【规则3-1-10】标识布尔型的变量或函数名称一般使用is作为前缀。
例如：void isFull()；
【规则3-1-11】常量全用大写字母，用下划线分割单词。
const int MAX_LENGTH = 100;
【规则3-1-12】静态变量加前缀s_（表示static）。
static int s_initValue; /* 静态变量*/
【规 则3-1-13】如果需要定义全局变量，则变量加前缀g_（表示global）。
例如：int g_howStudent;/* 全局变量*/
【规则3-1-14】函数名用大写字母开头的单词组合而成。由多个单词组成的标识符每个单词 首字母大写。其它小写。
例如：InputStudInfo();//全局函数
【规则3-1-15】一般错误包裹函数名全部大写。
例如：
FILE*pFile=fopen("readme.txt","rw+");
if ( pFile==NUL)
{
//错误处理：打印错误信息等。
abort()；
}
可以定义成下面的包裹函数
FILE *( charconst* fileName,char const *mode )
{
FILE*pFile=fopen(fileName,mode);
if (pFile==NUL )
{
//错误处理：打印错误信息等。
abort()；
}
returnpFile;//正常则返回相应的文件指针
}
以后调用的话，则可以使用下面的简洁方式:
FILE*pFile=FOPEN("readme.txt","rw++");
【建议3-1-1】尽量避免名字中出现数字编号，如value1、value2等，除非逻辑上的确需要编号。
4.常量（7条规则）
常量是一种标识符，它的值在运行期间恒定不变。C 语言用#define 来定义常量。除了#define之外还可以用const 来定义常量。
4.1const 与#define 的比较（2条规则）
C 语言可以用const 来定义常量，也可以用#define 来定义常量。但是前者比后者有更多的优点：
（1） const 常量有数据类型，而宏常量没有数据类型。编译器可以对前者进行类型安全检查。而对后者只进行字符替换，没有类型安全检查，并且在字符替换过程中可能会产生 意料不到的错误。
（2） 有些集成化的调试工具可以对const 常量进行调试，但是不能对宏常量进行调试。
【规则4-1-1】尽量使用 含义直观的常量来表示那些将在程序中多次出现的数字或字符串。
例如： #define MAX100 // C 语言的宏常量
const float PI = 3.14159; // C 语言的const常量
【规则4-1-2】尽量使 用const定义常量替代宏定义常量。
4.2 常量定义（5条规则）
【规则4-2-1】需要对 外公开的常量放在头文件中，不需要对外公开的常量放在定义文件的头部。为便于管理，可以把不同模块的常量集中存放在一个公共的头文件中。
【规则4-2-2】如果某 一常量与其它常量密切相关，则应在定义中包含这种关系，而不应给出一些孤立的值。
例如： const floatRADIUS = 100;
const float DIAMETER = RADIUS * 2;
【规则4-2-3】enum中的枚举常量应以大写字母开头或全部大写。
【规则4-2-4】如果宏值多于一项，一定使用括号。
例如：#defineERROR_DATA_LENGTH 10+1
应该这样定义：
#define ERROR_DATA_LENGTH (10+1)
这样使用malloc(5*ERROR_DATA_LENGTH)时，得到是 5*(10+1)=55; 而上面 的定义则得到5*10+1=51。
【规则4-2-5】函数宏的每个参数都要括起来。
例如：#defineWEEKS_TO_DAYS(w) (w*7)
应该写成：#define WEEKS_TO_DAYS(w) ((w)*7)
这样在翻译 totalDays＝WEEKS_TO_DAYS(1+2)时，才能够正确地翻译成：(1+2)*7；否则将错误地翻译成1+2*7。
5.变量（11条规则）
【规则5-1-1】局部变 量在引用之前要进行出初始化或要有明确的值。
【规则5-1-2】如果指针变量知道被初始化为什么地址，则初始化为该地址，否则初始化为NULL。
【规则5-1-3】所有的外部变量声明前都应加上extern关键字。
【规则5-1-4】尽量不要使用一个bit位控制程序流程或标识特定状态。最好使用多位或 枚举类型标识状态。
【规则5-1-5】如果定义数组时全部初始化，则不用给出数组长度。
例如：int array[]＝{1,2,3,4,5}；
在需要使用数组长度时，用sizeof(array)/sizeof(array[0]) 计算得出。
【规则5-1-6】不同文件的全局变量没有固定的初始化顺序，注意使用#include包括的文件都算作同一文件。
【规则5-1-7】尽量避免强制类型转换；如果不得不使用，则尽量使用显式方式。
【规则5-1-8】不要强制指针指向尺寸不同的目标。
例如：
int Function（constchar* pChar ）
{
int *pInt=(const int*)pChar;/*危险操 作*/
return(*pInt);
}
【规则5-1-9】尽量少使用无符号类型，其在混合表达式中可能隐式转换造成错误。
【规则5-1-10】尽量少的使用浮点类型，因为浮点数据标识不精确，而且运算速度慢。
【规则5-1-11】尽量少用union类型，因为成员共用内存空间，处理不当容易出 错。
6.表达式和基本语句（17条规则＋3条建议）
6.1 运 算符的优先级（1条规则）
【规则6-1-1】避免使 用默认的优先级。如果代码行中的运算符比较多，为了防止产生歧义并提高可读性，应当用括号明确表达式的计算顺序。
例如：value = (high<< 8) | low
if ((a | b) && (a & c) )
6.2 复合表达式（4条规则）
如a=b=c=0这样的表达式称为复合表达式。允许复合表达式存在的理由是：
（1） 书写简洁；
（2） 可以提高编译效率；
（3） 但要防止滥用复合表达 式。
【规则6-2-1】不要编写太复杂的复合表达式。
例如：i=a>= b&& c<d && c+f<=g+h ; // 复合表达式过于复杂
【规则6-2-2】不要使用 多用途的复合表达式。
例如：d=(a=b+c)+r ; //该表达式既求a 值又求d 值。
应该拆分为两个独立的语句：
a=b+c;
d=a+r;
【规则 6-2-3】不要把程序中的复合表达式与“真正的数学表达式”混淆。
例如： if( a<b<c) //a<b<c 是数学表达式而不是复合表达式
并不表示 if( (a<b) && (b<c) )
而是成了令人费解的 if( (a<b)<c )
【规 则6-2-4】“++”和“—”,当对语句中的变量使用递增或递减运算符时，该变量不应在语句中出现一次以上，因为求值的顺序取决于编译器。编写代码时不要对顺序作假 设，也不要编写在某一机器上能够如期运行但没有明确定义行为的代码。
例如：int i = 0, a[5];
a = i++; // 给a[0]赋值还是给a[1]赋值?
6.3if 语句布尔表达式（7条规则）
if 语句是C语言中最简单、最常用的语句，然而很多程序员用隐含错误的方式写if 语句。
【规则6-3-1】如 果布尔表达式比较长且与一个常值进行比较时,一般把常值放在前面更清楚。
例如：
if( 0!=(a+b)%6 )
{
}
【规则6-3-2】有多个if语句嵌套时，要层层对齐，每一层的真假分支使用括号括起来并对齐。
例如：
if( x>y )
{
}
else
{
if ( y>z)
{
}
else
{
}
}
规则6-3-3】布尔表达式中有多个逻辑“与”判断条件时，只要其中一个条件不满足则该表达式的值就是“假”；注意在else分支中，不能假定某个逻 辑表达式为“真”而进行处理，导致错误。
例如：
int a=10;
int b=0;
int c=0;
if（0!==a && 0!=b && 0!=c ）
{
}
else
{
x=y/c;
}
【规则6-3-4】布尔表达式中有多个逻辑“或”判断条件时，只要其中一个条件满足则该表达式的值就是“真”；注意不能假定某个逻辑表达式为“真”而进 行处理，导致错误。
例如：
int a=10;
int b=0;
int c=0;
if( 0!==a ||0!=b || 0!=c ）
{
x=y/c;
}
【规则6-3-5】不可将布尔变量直接与TRUE、FALSE或 者1、0 进行比较。
根据布尔类型的语义，零值为“假”（记为FALSE），任何非零值都是“真”（记为TRUE）。TRUE的值究竟是什么并没有统一的标准。例如Visual C++ 将TRUE 定义为1，而VisualBasic 则将TRUE 定义为-1。
假设布尔变量名字为flag，它与零值比较的标准if 语句如下：
if( flag) /* 表示flag 为真*/
if( !flag ) /*表示flag 为假*/
其它的用法都属于不良风格，例如：
if( flag ==TRUE )
if( flag == 1)
if( flag ==FALSE )
if( flag == 0)
【规则6-3-6】不可将浮点变量用“==”或“！=”与其它变量或数字比较。
千万要留意，无论是float 还是double 类型的变量，都有精度限制。所以一定要避免将浮点变量用“==”或“！=”与数字比较，应该设法转化成“>=”或“<=”的形式。
假设浮点变量为x，应当将
if( x == 0.0) // 隐含错误的比较
转化为
if((x>=-EPSINON ) && ( x<=EPSINON) )
其中EPSINON 是允许的误差（即精度）。
【规则6-3-7】应当将指针变量用“==”或“！=”与NULL比较。
指针变量的零值是“空”（记为NULL）。尽管 NULL 的值与0相同，但是两者意义不同。假设指针变量的名字为p，它与零值比较的标准if 语句如下：
if( p== NULL) // p 与NULL 显式比较，强调p 是指针变量
if( p!= NULL )
不要写成
if( p==0) // 容易让人误解p 是整型变量
if( p!=0 )
或者
if( p ) // 容易让人误解p 是布尔变量
if( !p )
6.4 循环语句（1条规则＋3条建议）
C语 言的循环语句中，for 语句的使用频率最高，while 语句其次，do 语句很少用。本节重点论述循环体的效率。提高循环体效率的基本办法是降低循环体的复杂性。
【规则6-4-1】不可在循环体内修改循环变量，以防止循环失去控制。
【建议6-4-1】在多重循环中，如果有可能，应当将最长的循环放在最内层，最短的循环放在最外层，以减少CPU 跨切循环层的次数。如下表的对比：
低 效率：长循环在最外层 高效率：长循环在最内层
for ( row=0;row<100; row++ )
{
for ( col=0;col<5; col++ )
{
sum = sum +a[row][col];
}
} for ( col=0; col<5; col++ )
{
for ( row=0;row<100; row++ )
{
sum = sum +a[row][col];
}
}
【建议6-4-2】如果循环体内存在逻辑判断，并且循环次数很大，宜将逻辑判断移到循环体的外面。下面示例a的程序比示例b程序多执行了N-1 次逻辑判断。并且由于前者总要进行逻辑判断，打断了循环“流水线”作业，使得编译器不能对循环进行优化处理，降低了效率。如果N非常大，最好采用示例b的 写法，可以提高效率。如果N非常小，两者效率差别并不明显，采用示例a的写法比较好，因为程序更加简洁。如 下表的对比：
a、效率低但程序简洁 b、 效率高但程序不简洁
for( i=0;i<N; i++ )
{
if ( condition)
DoSomething();
else
DoOtherthing();
}
if( condition )
{
for( i=0;i<N; i++ )
DoSomething();
}
else
{
for(i=0; i<N; i++)
DoOtherthing();
}
【建议6-4-3】建议for 语句的循环控制变量的取值采用“半开半闭区间”写法。
示例a中的x 值属于半开半闭区间“0 =< x< N”，起点到终点的间隔为N，循环次数为N。
示例b中的x 值属于闭区间“0 =< x<= N-1”，起点到终点的间隔为N-1，循环次数为N。
相比之下，示例a的写法更加直观，尽管两者的功能是 相同的。
a、循环变量属于半开半闭区间 b、循环变量属于闭区间
for( x=0;x<N; x++ )
{
...
} for( x=0; x<=N-1; x++ )
{
...
}
6.5switch 语句（2条规则）
【规则6-6-1】每个case 语句的结尾不要忘了加break语句，否则将导致多个分支重叠（除非有意使多个分支重叠）。
【规则6-6-2】不要忘记最后的default 分支。即使程序真的不需要default 处理，也应该保留语句default : break;
6.6goto 语句（1条规则）
【规则 6-7-1】慎用goto 语句。虽然在某些情况使用方便，但是会造成程序可读性下降。
7.函数设计（17条规则＋10条建议）
7.1注释规则（1条规则）
【规 则7-1-1】一般在函数头添加函数功能、参数说明、返回值等注释信息。可以选择在函数末尾添加该函数在单元测试中曾经出现的问题。
一个函数的注释信息如下例：
/**********************************************************************************
* Function(功能)：calculateThe area of rectangle *
* parameter(参数)：theLength and Width of rectangle *
* outout（返回值）：the area ofrectangle *
**********************************************************************************/
intGetValue(int iLength, int iWidth)
{
…
return iArea;
}
/*
Error:
1描述在单元测试中出现的错误
2…
*/
7.2 函数的使用（1条规则）
【规则7-2-1】函数的扇入数目尽量多，扇出数目不宜太多，一般不超过10，以保证 程序的高内聚、低藕和。
7.3 参数的规则（4条规则＋2条建议）
【规则7-3-1】参数的书写要完整，不要贪图省事只写参数的类型而省略参数的名字。如果函 数没有参数，则用void 填充。（使用函数原型）。
例如：
void SetValue(int width, int height); // 良好的风格
voidSetValue(int, int); // 不良的风格
floatGetValue(void); // 良好的风格
floatGetValue(); // 不良的风格
【规 则7-3-2】参数命名要恰当，顺序要符合习惯用法。
例如：编写字符串拷贝函数StringCopy，它有两个参数。如果把参数名字起为str1和str2，例 如:
void StringCopy(char *str1, char *str2);
很难搞清楚究竟是把str1 拷贝到str2 中，还是相反。可以把参数名字起得更有意义，例如strSource 和strDestination。这样从名字上就可以看出应该把strSource 拷贝到strDestination中。另外，参数的顺序要遵循库函数的风格。一般地，应将目的参数放在前 面，源参数放在后面。
【规则7-3-3】如果参数是指针，且仅作输入用，则应在类型前加const，以防止该指针在函数体内被意 外修改。
例如：void StringCopy(char *strDestination，constchar *strSource);
【规则7-3-4】对于基本数据类型参数应该传递值（除非函数要修改传入的参数），这样安 全、简单。对于复合数据类型应传递指针（地址），以提高效率。
【建议7-3-1】避免函数有太多的参数，参数个数尽量控制在5个以内。如果参数太多，在使用时容易将参数类型或顺序搞错。
【建议7-3-2】尽量不要使用类型和数目不确定的参数。
7.4 返回值的规则（6条规则）
【规则7-4-1】不要省略返回值的类型。如果函数没有返回值，那么应声明为void 类型。
【规则7-4-2】函数名字与返回值类型在语义上不可冲突。
【规则7-4-3】函数返回正 常值和错误标志要有明确的说明。
【规则 7-4-4】给以“指针传递”方式的函数返回值加const修饰，那么函数返回值（即指针）的内 容不能被修改，该返回值只能被赋给加const修饰的同类型指针。
函数返回值采用“值传递方式”，由于函数会把返回值复制到外部临时的存储单元中，加const修饰没有任何价值。
【规则7-4-5】返回指针类型的函数应该使用NULL表示失败。
【规则7-4-6】当函数返回指针时，应用注释描述指针的有效期。
7.5 函数内部实现的规则（2条规则）
不同功能的函数其内部实现各不相同，看起来似乎无法就“内部实现”达成一致的观点。但根据 经验，我们可以在函数体的“入口处”和“出口处”从严把关，从而提高函数的质量。
【规则7-5-1】在函数体的“入口处”，对参数的有效性进行检查。
【规则7-5-2】尽量保持函数只有一个出口，在函数体的“出口处”，对return 语句的正确性和效率进 行检查。
注意事项如下：
（1）return 语句不可返回指向“栈内存”的“指针”，因为该内存在函数体结束时被自动销毁。
例如:
char * Func(void)
{
char str[] = “hello student”;// str 的内存位于栈上
…
return str; // 将导致错误
}
（2）要搞清楚返回的究竟是“值”还是“指针”。
7.6 其它建议（6条建议）
【建议7-6-1】函数的功能要单一，不要设计功能过于复杂的函数。
【建议7-6-2】经常使用的重复代码用函数来代替。
【建议7-6-3】函数体的规模要小，尽量控制在50 行代码之内。
【建议7-6-4】尽量避免函数带有“记忆”功能。相同的输入应当产生相同的输出。函数的static 局部变量是函数的“记忆”存储器。建议尽量少用static 局部变量，除非必需。
【建议7-6-5】不仅要检查输入参数的有效性，还要检查通过其它途径进入函数体内的变量 的有效性。 例如全局变量、文件句柄等。
【建议7-6-6】用于出错处理的返回值一定要清楚，让使用者不容易忽视或误解错误情况。
7.7 使用断言（2条规则＋2条建议）
程序一般分为Debug 版本和Release 版本，Debug版本用于内部调试，Release 版本发行给用户使用。
断 言assert 是仅在Debug 中版本起作用的宏，它用于检查“不应该”发生的情况。在程序运行过程中，如果assert 的参数为假，那么程序就会中止（一般还会出现提示对 话，说明在什么地方引发了assert）。
assert 不是一个仓促拼凑起来的宏。为了不在程序的Debug 版本和Release 版本引起差别，assert 不应该产生任何副作用。所以assert 不是函数，而是宏。程序员可以把assert看成一个在任何系统状态下都可以安全使用的无害测试手段。如果程序在assert处终止了，并不是说明含有该assert 的函数有错误，而是调用者出了差错，assert 可以帮助我们找到发生错误的原因。
【规则7-7-1】使用断言捕捉不应该发生的非法情况。不要混淆非法情况与错误情况之间的 区别，后者是必然存在的并且是一定要作出处理的。
【规则7-7-2】在函数的 入口处，使用断言检查参数的有效性（合法性）。
【建议7-7-1】在编写函数时，要进行反复的考查，并且自问：“我打算做哪些假定？”一旦确定了的假定，就要使用断言对假定进行检查。
【建议7-7-2】一般教科书都鼓励程序员们进行防错设计，但要记住这种编程风格可能会隐瞒错误。当进行防错设计时，如果“不可能发生”的事情的确发 生了，则要使用断言进行报警。
8.内存管理（5条规则）
8.1 内存使用注意的问题（5条规则）
内存分配方式有三种：
（1） 从静态存储区域分配。内存在程序编译的时候就已经分配好，这块内存在程序的整个运行期间都存在。例如全局变量，static 变量。
（2） 在栈上分配。在执行函数时，函数内局部变量的存储单元都在栈上创建，函数执行结束时这些存储单元自动被释放。栈内存分配运算内置于处理器的指令集中，效率 很高，但是分配的内存容量有限。
（3） 从堆上分配，亦称动态内存分配。程序在运行时用malloc或calloc申请任意大小的内存，程序员自己负责在何时用free释放内存。动态内存的生存期由程序员决定，使用非常灵活， 但问题也最多。
【规则8-1-1】用 malloc或calloc申请内存之后，应该立即检查指针值是否为NULL。防止使用指针值为NULL 的内存。
【规则8-1-2】不要忘 记为数组和动态内存赋初值。防止将未被初始化的内存作为右值使用。
【规则8-1-3】避免数组或指针的下标越界，特别要当心发生“多1”或者“少1”操作。
【规则8-1-4】动态内存 的申请与释放必须配对，防止内存泄漏。
【规 则8-1-5】用free释放内存之后，应立即将指针设置为NULL，防止产生“野指针”。
9.其他规范及建议（27条建议）
9.1 提高程序的效率（6条建议）
程序的时间效率是指运行速度，空间效率是指程序占用内存或者外存的状况。全局效率是指站在 整个系统的角度上考虑的效率，局部效率是指站在模块或函数角度上考虑的效率。
【建议9-1-1】不要一味地追求程序的效率，应当在满足正确性、可靠 性、健壮性、可读性等质量因素的前提下，设法提高程序的效率。
【建议9-1-2】以提高 程序的全局效率为主，提高局部效率为辅。
【建 议9-1-3】在优化程序的效率时，应当先找出限制效率的“瓶颈”，不要在无关紧要之处优化。
【建议9-1-4】先优化 数据结构和算法，再优化执行代码。
【建 议9-1-5】有时候时间效率和空间效率可能对立，此时应当分析哪个更重要，做出适当的折衷。例 如多花费一些内存来提高性能等。
【建议 9-1-6】不要追求紧凑的代码，因为紧凑的代码并不能产生高效的机器码。
9.2 编译问题（2条建议）
【建议9-2-1】把编译器的选择项设置为最严格状态。在调试代码时应该将编译器的所有警告 信息都打开，并且编译不包括任何警告信息。把问题尽量暴露在编译时而不是运行时，尽量减少解决的代价。
【建议9-2-2】对于大型软件尽量减少编译时间。例如调试时关闭优化选项，尽量减少文件 之间的依赖程度。
9.3 兼容性问题（8条建议）
【建议9-3-1】尽量不要使用与具体硬件或软件环境关系密切的变量。
【建议9-3-2】遵守ANSI国际标准，将不符合标准的代码与其它代码分开并进行标记，将依赖特 定硬件或操作系统的代码分开。
【建议9-3-3】不要假设各数据类型的尺寸。
【建议9-3-4】注意不 能设定数据溢出处理方式。
【建议 9-3-5】不能假设表达式的运算顺序。
【建议9-3-6】不要假设 参数的计算顺序。
【建议9-3-7】注意数据文件的兼容性，例如：字节排列顺序，数据对齐方式，行尾标志等。
【建议9-3-8】尽量使用 标准库函数, 不要“发明”已经存在的库函数。
9.4性能问题（4条建议）
【建 议9-4-1】不要使用移位代替乘除操作，一般编译器会作优化。
【建议9-4-2】不要使用关键字register，一般编译器会作优 化。
【建议9-4-3】避 免在循环体内定义变量。
【建议9-4-4】前缀++和--的效率高于后缀的++和--。
9.5 其他一些有益的建议（7条建议）
【建议9-5-1】当心那 些视觉上不易分辨的操作符发生书写错误。例如经常会把“＝＝”误写成“＝”，像“||”、“&&”、“<=”、“>=”这类符号也很容易发生“丢失”错误。然而编译器却不一定能自动指出这类错误。
【建议9-5-2】当心变量 的初值、缺省值错误，或者精度不够。
【建 议9-5-3】当心数据类型转换发生错误。尽量使用显式的数据类型转换，避免让编译器轻悄悄地进 行隐式的数据类型转换。
【建议 9-5-4】当心变量发生上溢或下溢，以及数组的下标越界。
【建议9-5-5】当心忘 记编写错误处理程序，当心错误处理程序本身有误。
【建议9-5-6】在工程中编写程序时，避免编写技巧性很高的代码。
【建议9-5-7】如果可能的话，使用代码规则检查工具进行代码检查。
850
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
