目录
C代码编写规范.......................................................................... 错误！未定义书签。概述.. (3)
规则 (3)
1.1 文件结构 (3)
1.1.1 文件扩展名 (3)
1.1.2 版权和版本的声明 (3)
1.1.3 头文件和定义文件结构 (4)
1.2 程序排版 (7)
1.2.1 概述 (7)
1.2.2 缩进、空行、空格与对齐 (7)
1.2.3 长行拆分 (9)
1.2.4 修饰符的位置 (10)
1.2.5 注释 (10)
1.2.6 可读性 (12)
1.2.7 自定义类型 (13)
1.2.8 预编译指令 (14)
1.3 命名规则 (15)
1.3.1 基本原则 (15)
1.3.2 具体命名原则 (15)
1.4 表达式和基本语句 (17)
1.4.1 表达式 (17)
1.4.2 基本语句 (17)
1.4.3 常量规则 (18)
1.4.4 变量规则 (19)
1.4.5 结构 (19)
1.5 函数规则 (22)
1.5.1 参数规则 (22)
1.5.2 返回值的规则 (22)
1.5.3 函数内部规则 (23)
1.5.4 函数使用方法 (23)
1.5.5 函数建议 (25)
1.5.6 断言 (26)
1.6 代码编辑、编译与审查 (27)
1.6.1 代码编辑 (27)
1.6.2 代码编译 (27)
1.6.3 代码审查 (28)
1.7 代码测试与维护 (28)
1.8 宏 (29)
1.9 程序效率 (29)
1.10 质量保证 (31)
附件 (33)
1.11 附件一运算符顺序 (33)
1.12 附件二英文常用缩写 (34)
概述
本文档的目的在于规范C代码撰写，所有软件工程师提交代码必须严格按照本文档执行。
规则
1.1文件结构
1.1.1文件扩展名
每个C程序分为两个文件。一个文件用于保存程序的声明(declaration)，为头文件。另一个文件用于保存程序的实现(implementation)，为定义(definition)文件。
C程序的头文件以“.h”为后缀，C程序的定义文件以“.c”为后缀。
1.1.2版权和版本的声明
版权和版本的声明位于头文件和定义文件的开头。主要内容有：
1.版权信息；
2.文件名称，标识符，摘要；
3.当前版本号，作者/修改者，完成日期；
具体的定义如下：
/*
***********************************Copyright (c)********************************
*
*-------------------------------------------------------------------------------
* 文件名: ???.c
* 文件描述: ???
*
* 作者: (姓名、邮箱，QQ等)
* 创建日期: 2009-12-01
*
* 编译环境: Tornado2.0&Wind River Workbench 3.0 TOOL=diab
* 硬件环境: ATMEL AT91SAM9G20 fclk=400M
*-------------------------------------------------------------------------------
* 初始版本： V1.0
*
*----------------------------------修改记录-------------------------------------
* 修改人: 甲乙丙丁
* 修改日期: 2010.8.4
* 当前版本： V1.1
* 修改描述: 新增任务tidtaskTouchScreen
*-------------------------------------------------------------------------------
********************************************************************************
*/
代码区
/*
********************************************************************************
* End Of File
********************************************************************************/
注意：
1.版权版本信息和文件信息必须出现在文件的最开始；
2.其中修改者信息不止一项。当第一位修改者修改完成后，提交到版本
库时，必须填写修改者姓名、修改日期、修改的版本号以及修改描述；
当第二位修改者修改后，在提交到版本库之前，也必须填写相关修改
信息；
3.所有文件必须以”End Of File”字样结束，文件最后空一行；
4.代码区与文件头、尾信息之间各空一行。
1.1.3头文件和定义文件结构
1.1.3.1头文件结构
一般头文件由四部分内容组成：
1.头文件开头处的版权声明和相关信息，详细规则见1.1.2；
2.预处理块，定义宏的区域，必须使用以下的注释，所有定义紧跟注释
之后，不得出现在别的位置；
/****************************************************************************
* Macros
****************************************************************************/
3.定义数据类型，所有数据类型紧跟注释之后，不得出现在别的位置；/****************************************************************************
* Local Types
****************************************************************************/
4.函数声明。对于普通函数声明，声明必须紧跟着定义的函数接口说明
(参见定义文件第8部分)，并且函数接口说明和定义文件中的接口说明
必须是一致的。
1.1.3.2定义文件结构
定义文件由八个部分组成：
1.定义文件开头处版权声明和相关信息，详细规则见1.1.2；
2.定义该文件包含的头文件列表，所有#include语句只能出现在以下注
释之后，不得出现在别的位置；
/****************************************************************************
* Include Files
****************************************************************************/
3.定义该文件使用的常量宏，该文件使用的宏(除个别控制编译的宏)必须
出现在以下注释之后，不得出现在别的位置；
/****************************************************************************
* Macros
****************************************************************************/
4.定义该文件使用的局部类型，该文件中使用的局部数据类型，必须出
现在以下注释之后，不得出现在别的位置；
/****************************************************************************
* Local Types
****************************************************************************/
5.定义该文件使用的局部常量，该文件使用的常量(const定义)必须出
现在以下注释之后，不得出现在别的位置；
/****************************************************************************
* Manifest Constant
****************************************************************************/
6.定义该文件使用的局部静态变量，该文件使用的静态变量(static定
义)必须出现在以下注释之后，不得出现在别的位置；
/****************************************************************************
* Static Variables
****************************************************************************/
7.定义该文件使用的局部静态函数原型，该文件使用的内部函数(static
定义)原型必须出现在以下注释之后，不得出现在别的位置；
/****************************************************************************
* Internal Function Prototypes
****************************************************************************/
8.定义该文件所提供的函数接口，每个函数或方法前必须加上以下注释。/*
********************************************************************************
* 函数名: Fuc_Demo()
* 功能描述: ？？？
* 输入参数: void
* 返回值: void
* 注释: 1).通过更改宏定义__USED_AS_EXHIBIT__为TRUE来调用该函数
2).开机3秒后进入演示模式
********************************************************************************/
1.1.3.3注意事项
1.如果.h文件是函数原型文件，使用宏只让其编译一次。紧跟头文件版
权版本信息之后，定义如下宏；
#ifndef __大写的文件名_H__
#define __大写的文件名_H__
/*头文件的四个部分*/
#endif /* __大写的文件名_H__ */
2.不准在头文件内添加任何变量的定义；
3.如果.h文件中含有的是函数的配置宏，应使用宏命令，让其只能和配
对的C文件一同使用；
/*这是设备配置的头文件devCfg.h*/
#ifdef USE_UART_CONFIG
/*定义UART设置*/
#endif
#ifdef USE_SPI_CONFIG
/*定义SPI设置*/
#endif
/*这是使用uart.cpp文件，需要使用devCfg.h文件*/
...
#define USE_UART_CONFIG
#include
...
1.2程序排版
1.2.1概述
程序的排版追求清晰、美观，是程序风格的重要构成因素，有利于代码的阅读和维护。为了统一排版格式，以在Source Insight/UltraEdit等代码编辑器为基础，定义所有的排版标准。
1.2.2缩进、空行、空格与对齐
1.2.2.1缩进
缩进：为了避免不同编辑器对TAB键的解释不同，所有缩进全部使用空格键，不得使用TAB键（有时为了编辑的便捷，可在编辑器中将TAB键设置为由空格键代替，此时，可使用TAB键）。
1.函数或过程的开始、结构的定义及循环、判断等语句中的代码都要采
用缩进风格；
2.case语句下的情况处理语句也要遵从语句缩进要求；
3.本文后面所说的缩进，在无特殊说明的情况下，都是指缩进一个单位，
即4个空格。（本文所有缩进都是以一个单位，即4个空格进行）
1.2.2.2空行
空行是用以区分不同的程序块，程序块间，加上空行以示区分。
1.函数空行：在每个函数定义结束之后都要加空行。函数内部的空行，
在一个函数体内，逻辑上密切相关的语句之间不加空行，其它地方应
加空行分隔；
2.代码空行：一行代码只做一件事情，如只定义一个变量，或只写一条
语句。这样的代码容易阅读，并且方便于写注释。if、for、while、
do等语句自占一行，执行语句不得紧跟其后。不论执行语句有多少都
要加{}。如：
...
THANDLE hProcess;
TPROCESS_T procInfo;/* open the process handle */
if((hProcess = OpenProcess(PROCESS_ALL, FALSE, pid)) == NULL)
{
return LSE_MISC_SYS;
}
memset(&procInfo, 0, sizeof(procInfo));
procInfo.idProc = pid;
procInfo.hdProc = hProcess;
procInfo.misc &= MSCAVA_PROC;
return(0);
...
1.2.2.3空格
1.数名之后不要留空格，紧跟左括号‘(’，以与关键字区别；
2.‘(’向后紧跟；‘)’、‘,’、‘;’向前紧跟，紧跟处不留空格；
3.‘,’之后要留空格，如Function(x, y, z)。如果‘;’不是一行的
结束符号，其后要留空格，如: for (initialization; condition;
update)；
4.赋值操作符、比较操作符、算术操作符、逻辑操作符、位域操作符，
如‘=’、‘+=’、‘+’等二元操作符的前后应当加空格；
5.一元操作符如‘++’、‘--’、‘*(Address)’等前后不加空格；
6.‘[]’、‘.’、‘->’~这类操作符前后不加空格；
7.关键字之后要留空格。像const、virtual、inline、case等关键字
之后至少要留一个空格，否则无法辨析关键字。像if、for、while
等关键字之后应留一个空格再跟左括号‘(’，以突出关键字；
8.对于表达式比较长的for 语句和if 语句，为了紧凑起见可以适当地
去掉一些空格，如for (i=0; i<10; i++)和if ((a<=b) && (c<=d))，
括号与数字、变量之间是没有空格的；
9．代码行（只要有字符的都算）的末尾不得出现冗余的空格。（有些编辑器在回车换行时自动与上一行对齐，如果此行不添加任何代码或字符，
可不必删除这些编辑器自动添加的空格）
1.2.2.4对齐
1.程序的分界符‘{’和‘}’应独占一行并且位于同一列，同时与引用
它们的语句左对齐；
2.{}之内的代码块在‘{’右边缩进一个单位处左对齐；
3.建议：用空格键对齐变量的声明或注释，让程序美观一些。如：
typedef struct _ptverb_manverb_tverb_{
TINT numProc; /* Number of processes*/
TINT maxProc; /* Max Number of processes*/
TINT numEvnt; /* Number of events*/
TINT maxEvnt; /* Max Number of events*/
} TPtManT;
1.2.3长行拆分
1.代码行最大长度控制在70 至80 个字符以内，长度超过80个字符时，
必须换行；
2.长表达式要在低优先级操作符处拆分成新行，操作符放在新行之首(以
便突出操作符)。拆分出的新行要进行适当的缩进，使排版整齐，语句
可读。如：
if ((very_longer_variable1 >= very_longer_variable12)
&& (very_longer_variable3 <= very_longer_variable14)
&& (very_longer_variable5 <= very_longer_variable16))
{
dosomething();
}
virtual CMatrix CMultiplyMatrix (CMatrix leftMatrix,
CMatrix rightMatrix);
for (very_longer_initialization;
very_longer_condition;
very_longer_update)
{
dosomething();
}
#define MACRO_DEFINE() do \
{ \
sentence1;\
sentence2;\
sentence3;\
sentence4;\
} while (0)
3.循环、判断等语句中若有较长的表达式或语句，则要进行适当的划分，
长表达式要在低优先级操作符处划分新行，操作符放在新行之首。如：if ((taskno < max_act_task_number)
&& (n7stat_stat_item_valid (stat_item)))
{
... // program code
}
for (i = 0, j = 0; (i < BufferKeyword[word_index].word_length)
&& (j < NewKeyword.word_length); i++, j++)
{
... // program code
}
for (i = 0, j = 0;
(i < first_word_length) && (j < second_word_length);
i++, j++)
{
... // program code
}
4.若函数或过程中的参数较长，则要进行适当的划分。如：
n7stat_str_compare((BYTE *) & stat_object,
(BYTE *) & (act_task_table[taskno].stat_object),
sizeof (_STAT_OBJECT));
n7stat_flash_act_duration( stat_item, frame_id *STAT_TASK_CHECK_NUMBER
+ index, stat_object );
1.2.4修饰符的位置
将修饰符‘*’和‘&’紧靠变量名。如：
int *mCurBufPos;
char *btsName;
int &aliasBuf = Buf;
1.2.5注释
注释是对重要的代码行或段落进行提示(注释的其他用法请参考1.1文件结构)。
1.一律不得使用‘//’，注释只能使用‘/* 注释内容 */’，注释内容前后各留
一个空格；
2.如果代码本来就是清楚的，则不必加注释；
3.边写代码边注释，修改代码同时修改相应的注释，以保证注释与代码
的一致性。不再有用的注释要删除；
4.注释应当准确、易懂，防止注释有二义性；
5.在注释中避免使用缩写，特别是不常用的缩写；
6.注释的位置应与被描述的代码相邻，可以放在代码的上方或右方，不
可放在下方；
7.对于所有有物理含义的变量、常量，如果其命名不是充分自注释的，
在声明时都必须加以注释，说明其物理含义。变量、常量、宏的注释
应放在其上方相邻位置或右方。如：
/* active statistic task number */
#define MAX_ACT_TASK_NUMBER 1000
#define MAX_ACT_TASK_NUMBER 1000 /* active statistic task number */
8.当代码比较长，特别是有多重嵌套时，应当在一些段落的结束处加注
释，便于阅读。如：
if (...)
{
...
while (...)
{
...
} /* end of while*/
...
} /* end of if*/
9.避免在一行代码或表达式的中间插入注释；
10.通过对函数或过程、变量、结构等正确的命名以及合理地组织代码的
结构，使代码成为自注释的；
11.在代码的功能、意图层次上进行注释，提供有用、额外的信息，帮助
读者理解代码，防止没必要的重复注释信息；
12.注释应考虑程序易读及外观排版的因素，使用的语言若是中、英兼有
的，建议多使用中文，除非能用非常流利准确的英文表达，禁止使用
拼音、拼音与英文混合注释；
13.对变量的定义和分支语句（条件分支、循环语句等）必须编写注释；
14.于switch语句下的case语句，如果因为特殊情况需要处理完一个
case后进入下一个case处理，必须在该case语句处理完、下一个case
语句前加上明确的注释，有效防止无故遗漏break语句。如：case CMD_UP:
ProcessUp();
break;
case CMD_DOWN:
ProcessDown();
break;
case CMD_FWD:
ProcessFwd();
if (...)
{
...
break;
}
else
{
ProcessCFW_B(); // now jump into case CMD_A
}
case CMD_A:
ProcessA();
break;
case CMD_B:
ProcessB();
break;
case CMD_C:
ProcessC();
break;
case CMD_D:
ProcessD();
break;
...
1.2.6可读性
1.注意运算符的优先级，并用括号明确表达式的操作顺序，避免使用默
认优先级。要求含两个或两个以上操作符的表达式必须用括号标识优
先级。如：
word = (high << 8) | low (1)
if ((a | b) && (a & c)) (2)
if ((a | b) < (c & d)) (3)
如果书写为
high << 8 | low
a |
b && a & c
a |
b <
c & d
由于
high << 8 | low = ( high << 8) | low,
a |
b && a &
c = (a | b) && (a & c),
(1)(2)不会出错，但语句不易理解；
a |
b <
c &
d = a | （b < c） & d,(3)造成了判断条件出错。
2.避免使用不易理解的数字，用有意义的标识来替代。涉及物理状态或
者含有物理意义的常量，不应直接使用数字，必须用有意义的枚举或
宏来代替。如：
if (Trunk[index].trunk_state == 0)
{
Trunk[index].trunk_state = 1;
... // program code
}
应改为如下形式。
#define TRUNK_IDLE 0
#define TRUNK_BUSY 1
if (Trunk[index].trunk_state == TRUNK_IDLE)
{
Trunk[index].trunk_state = TRUNK_BUSY;
... // program code
}
3.源程序中关系较为紧密的代码应尽可能相邻；
4.不要使用难懂的技巧性很高的语句，除非很有必要时。
1.2.7自定义类型
1.2.7.1struct/enum/union
1.如果是struct/enum/union类型，必须在定义时使用typedef；
2.大括号左端和typedef为同一行，不另起新行；
3.struct/enum/union类型名称上必须加上tag前缀，而typedef定义
的类型名称只是将struct/enum/union类型名称去掉tag前缀，加上
‘T’前缀；
4.内部定义必须缩进一个单位。
/*used for debugging, report error*/
typedef struct tagInfoHeader {
TINT32 v1;
TINT32 v2;
TUINT32 v3;
} TInfoHeader;
/*used for identify device */
typedef enum tagDeviceType {
dtNvRAM,
dtLCD,
dtPrinter,
dtADC,
dtDAC,
dtUART,
dtSPI,
} TDeviceType;
1.2.8预编译指令
1.预编译指令不受当前代码的缩进的影响，第一个预编译指令是不缩进；
2.若编译指令存在嵌套逻辑关系，缩进一个单位，以增强代码的可读性；
3.代码的缩进不受预编译指令的影响。
#include
#ifdef WIN32
#ifdef DEBUG
#define WIN32_DEBUG
#endif
#endif
int Func()
{
#ifdef WIN32_DEBUG
return (1);
#else
#ifdef WIN32
return (2);
#endif
#endif
}
1.3命名规则
1.3.1基本原则
1.标识符应该由其作用、目的来命名，应当直观且可以拼读，可望文知
意，不必进行“解码”；
2.标识符最好采用英文单词或其组合，便于记忆和阅读，切忌使用汉语
拼音、或拼音与英文的组合体来命名，程序中的英文单词一般不会太
复杂，用词应当准确；
3.标识符的长度应当符合最小长度表达最大信息的原则；
4.识符最好采用英文单词或其组合，便于记忆和阅读。如果过名字过长，
采用简写(见附件)；
5.程序中不要出现仅靠大小写区分的相似的标识符；
6.程序中不要出现标识符完全相同的局部变量和全局变量，尽管两者的
作用域不同而不会发生语法错误，但会使人误解；
7.用正确的反义词组命名具有互斥意义的变量或相反动作的函数等。使
用“名词”或者“形容词+名词”作为变量命名的主要元素；使用“动
词+名词”作为函数命名的主要元素。如下所示；
int minValue;
int maxValue;
int SetValue(. . .);
int GetValue(. . .);
8.尽量避免名字中出现数字编号，如Value1/Value2等，除非逻辑上的
确需要编号如Uart0/Uart1等。
1.3.2具体命名原则
1.局部变量：变量名首单词的字母小写，其他单词首字母应大写，非首
字母均小写。注意：作用域在单个C文件内的局部变量必须用static
关键字进行修饰；
char uartTxBuf; /* Uart口发送缓冲区 */
float curChargeCur; /* 当前充电电流 */
int curBatIR; /* 当前电池内阻 */
int *textBuf; /* 指向文字缓冲区的指针 */
int *uartTxBuf; /* 指向uart发送缓冲区的指针 */
static int localSem；/* 局部信号量 */
2.全局变量：变量名所有单词的首字母大写，其他字母小写，并在变量
前加上g_前缀；
int g_ScreenType; /* 当前电池内阻 */
int *g_LcdBuff; /* 指向文字缓冲区的指针 */
3.
4.常量：const定义的常量满足规则1的前提下，具有_cnt 前缀，第
一个单词的首字母大写。由#define 定义的常量单词全部大写，当超
过两个以上单词时，每个单词之间加_分隔；
const int _cntMaxValue = 100;
#define NULL (0)
#define CMD_READ_SPI_LINE "read spi"
5.函数名、函数指针：每个单词的首字母大写，其他字母全部小写。函
数指针不加任何后缀。注意：作用域在单个C文件内的局部函数名全
部小写，并用关键字static进行修饰；
char (*GetRxChar)();
char SpiGetRxChar();
char UartGetRxChar();
GetRxChar = SpiGetRxChar;
GetRxChar = UartGetRxChar;
6.数据类型名：使用typedef 定义的数据类型名称必须加上T前缀。单
词首字母大写，其他字母均小写；紧跟struct/union/enum 的类型
名加上tag前缀。不容许出现匿名结构/联合/枚举；
typedef int TINT;
typedef struct tagVirtualNode {
TDataType data;
struct tagVirtualNode *next;
} TVirtualNode;
7.枚举值命名：必须加上该枚举类型名称中所有单词首字母组成的前缀，
前缀中的字母均小写。单词首字母大写，其他字母均小写；
typedef enum tagDeviceType {
dtNvRAM,
dtLCD,
dtPrinter,
} TDeviceType;
8.结构/联合成员名：结构/联合成员名称命名规则同规则1；
9.函数/方法参数命名：如果参数是用来供函数使用的，并不利用其返回
值，加上in 前缀；如果参数用来返回值，加上o 前缀；如果参数既
传递参数给函数，也从函数内返回值，使用io 前缀；注意：如果是
带in 前缀的指针参数，必须加const 符号进行修饰。
void GetBiggestIdx(const TINT *inBuff, TINT ioSize, TINT *oIdx);
1.4表达式和基本语句
1.4.1表达式
1.如果代码行中的运算符比较多，用括号确定表达式的操作顺序，避免
使用默认的优先级；
word = (high << 8) | low;
while ((a | b) && (a & c) && (a ^ d))
2.不要编写太复杂的复合表达式；不要有多用途的复合表达式；不要把
程序中的复合表达式与数学抽象表达式混淆；
i = a >= b && c < d && c + f <= g + h /* 复合表达式过于复杂 */
d = (a = b + c) + r /* 既求a的值又求b的值，应该拆分为两个独立的语句 */
if (a < b < c) /* a < b < c 是数学表达式不是程序表达式 */
a =
b = c; /* 用
c 对 a 和 b 连续的赋值，合理的复合表达式 */
3.逻辑表达式：逻辑表达式中数值和函数写在运算符左侧，变量写在运
算符右侧；
NULL == mBuf
GetValue() < value
UpperBoundary() == index
1.4.2基本语句
1.4.
2.1if 语句
1.不可将布尔变量直接与~TRUE、~FALSE~或者~1、~0~进行比较；
if (flag) /* 表示flag为真 */
if (!flag) /* 表示flag为假 */
2.应当将整型变量用‘==’或‘!=’直接与0比较；
3.不可将浮点变量用‘==’或‘!=’与任何数字比较；千万要留意，无
论是float还是double类型的变量，都有精度限制。所以一定要
避免将浮点变量用==或!=与数字比较，应该设法转化成>=或<=
形式。假设浮点变量的名字为x，应当将if (x == 0.0) 转化为if
((x >= -EPSINON) && (x <= EPSINON)) 其中EPSINON是允许的误
差（即精度）；
4.将指针变量用‘==’或‘!=’与NULL比较；
5.if 语句有多于一个分支时，必须具有else 分支；
1.4.
2.2for 语句
1.不可在 for循环体内修改循环变量，防止 for循环失去控制；
2.for语句的循环控制变量的取值采用“半开半闭区间”写法；
3.for语句里初使化不容许声明变量；
4.条件位置也不容许出现与循环变量无关的条件；
5.增量位置也不容许出现与循环变量无关的语句。
1.4.
2.3switch 语句
1.每个case语句的结尾不要忘了加break，否则将导致多个分支重叠
(除非有意使多个分支重叠)；
2.case关键字和default关键字与switch关键字之间缩进一个单位。
break关键字和语句与case关键字之间缩进一个单位；
3.即使程序真的不需要default处理，也应该保留语句default : break;
语句。
1.4.
2.4goto 语句
goto语句只能有以下一种用法：从多重循环体中跳出，不使用break语句(除非使用一条break语句即可跳出循环)，采用 goto 语句直接跳出多重循环。除去以上的用法以外，不准在其他场合下使用goto语句。
1.4.3常量规则
1.4.3.1概述
当程序中出现大量的立即数，程序的可读性变差。在程序的很多地方输入同样的数字或字符串，难保不发生书写错误。如果要修改数字或字符串，则会在很多地方改动，既麻烦又容易出错。所以尽量使用含义直观的常量来表示那些将在程序中多次出现的数字或字符串。
1.4.3.2定义规则
1.需要对外公开的常量放在头文件中，不需要公开的常量放在定义文件
的头部；
2.如果某一常量与其它常量密切相关，应在定义中包含这种关系，而不应
给出一些孤立的值。例如：
char float RADIUS=100.0;
char float DIAMETER= RADIUS﹡2.0;
3.如果是整型取值，范围又不大的常量(不超过整型变量的取值范围)可以
采用枚举型变量定义。
1.4.4变量规则
1.去掉没必要的公共变量。公共变量是增大模块间耦合的原因之一，故
应减少没必要的公共变量以降低模块间的耦合度；
2.当向公共变量传递数据时，要十分小心，防止赋与不合理的值或越界
等现象发生。对公共变量赋值时，若有必要应进行合法性检查，以提
高代码的可靠性、稳定性；
3.防止局部变量与公共变量同名。若使用了较好的命名规则，那么此问
题可自动消除；
4.严禁使用未经初始化的变量作为右值。在C中引用未经赋值的指针，
经常会引起系统崩溃；
5.使用严格形式定义的、可移植的数据类型，尽量不要使用与具体硬件
或软件环境关系密切的变量。如下例子，在移植时可能产生问题。
void main()
{
register int index; // 寄存器变量
_AX = 0x4000; // _AX是BC3.1提供的寄存器“伪变量”
... // program code
}
1.4.5结构
1.结构的功能要单一，是针对一种事务的抽象。设计结构时应力争使结
构代表一种现实事务的抽象，而不是同时代表多种。结构中的各元素
应代表同一事务的不同侧面，而不应把描述没有关系或关系很弱的不
同事务的元素放到同一结构中；
2.不要设计面面俱到、非常灵活的数据结构，反而容易引起误解和操作
困难；
3.同结构间的关系不要过于复杂。若两个结构间关系较复杂、密切，那
么应合为一个结构；
示例：如下两个结构的构造不合理。
typedef struct PERSON_ONE_STRU
{
unsigned char name[8];
unsigned char addr[40];
unsigned char sex;
unsigned char city[15];
} PERSON_ONE;
typedef struct PERSON_TWO_STRU
{
unsigned char name[8];
unsigned char age;
unsigned char tel;
} PERSON_TWO;
由于两个结构都是描述同一事物的，那么不如合成一个结构。
typedef struct PERSON_STRU
{
unsigned char name[8];
unsigned char age;
unsigned char sex;
unsigned char addr[40];
unsigned char city[15];
unsigned char tel;
} PERSON;
4.结构中元素的个数应适中。若结构中元素个数过多可考虑依据某种原
则把元素组成不同的子结构，以减少原结构中元素的个数；
示例：假如认为如上的_PERSON结构元素过多，那么可如下对之划分。typedef struct PERSON_BASE_INFO_STRU
C语言注释规范 1.注释原则 同一软件项目开发中，尽量保持代码注释规范和统一。 注释方便了代码的阅读和维护。 边写代码边注释，修改代码时要相应修改注释，保证注释和代码的一致性。 注释要简洁明确，不要出现形容词。 对于写的好的注释，我们将是第一个受益者。 大型软件开发中，通过别人的注释可以快速知道他人所写函数的功能，返回值，参数的使用。 2.文件头部的注释 示例： / * Program Assignment : 该文件的作用 * Author: 作者 * Date: 2013/8/6 14:34 * Description: 该文件的描述 *****/ /* * Source code in : 源代码的路径 * Function List: * initLinear 初始化线性表 * destoryLinear 释放线性表申请的空间 * isLinearEmpty 判断线性表是否为空 * isLinearFull 判断线性表是否为满 * getLinearElementValue 取得下标为index的元素的值 */ 注意：这个函数列表可以快速查询到我们想要了解的函数。 3.结构体，全局变量等的注释 示例： typedef POLYNOMIAL USER_TYPE; /* 新的数据类型的描述*/ int a; /* 全局变量的作用*/ /* 说明结构体的功能*/ typedef struct LINEAR { USER_TYPE *data; /* 每个成员的意义(作用) */ int maxRoom; /* 每个成员的意义(作用) */
int elementCount; /* 每个成员的意义(作用) */ }LINEAR; 4.函数的注释 在逻辑性较强的的地方加入注释，以便其他人的理解，在一定的程度上排除bug。 示例： /* * Function Name: getLinearElementIndex * Purpose: 取得元素的index值 * Params : * @LINEAR linear 线性表实例 * @USER_TYPE var 类型为USER_TYPE的实例 * @int (*)() cmp 提供接口，让用户定义具体比较函数 * Return: int 返回元素的index值 * Limitation: 如果返回-1，则代表不存在var的元素 */ int getLinearElementIndex(LINEAR linear, USER_TYPE var, int (*cmp)()) { /* * 如果逻辑太过复杂，这里写明该算法的过程和思路。 */ boolean found = FALSE; int i; for(i = 0; i < && !found; i++) if(cmp[i], var) == 0) found = TRUE; if(i >= i = NOT_FOUND; return i; }
C语言编程规范 对于程序员来说，能工作的代码并不等于“好”的代码。“好”代码的指标很多，包括易读、易维护、易移植和可靠等。其中，可靠性对嵌入式系统非常重要，尤其是在那些对安全性要求很高的系统中，如飞行器、汽车和工业控制中。这些系统的特点是：只要工作稍有偏差，就有可能造成重大损失或者人员伤亡。一个不容易出错的系统，除了要有很好的硬件设计(如电磁兼容性)，还要有很健壮或者说“安全”的程序。 然而，很少有程序员知道什么样的程序是安全的程序。很多程序只是表面上可以干活，还存在着大量的隐患。当然，这其中也有C语言自身的原因。因为C语言是一门难以掌握的语言，其灵活的编程方式和语法规则对于一个新手来说很可能会成为机关重重的陷阱。同时，C语言的定义还并不完全，即使是国际通用的C语言标准，也还存在着很多未完全定义的地方。要求所有的嵌入式程序员都成为C语言专家，避开所有可能带来危险的编程方式，是不现实的。最好的方法是有一个针对安全性的C语言编程规范，告诉程序员该如何做。 本规范在制定过程中，主要参考了业界比较推崇的《华为软件编程规范和范例》和《MI SRA 2004规则》，适合C语言初学者使用，目的在于在教学中培养学生良好的编程规范和意识、素质，促进所设计程序安全、健壮、可靠、可读与可维护(程序简单、清晰)。考虑到面向的是初学者，为便于教学和课程考核操作，本规范中的要求比较基本。事实上，很多公司都有自己规定的代码风格，包括命名规则、缩进规则等，学生参加工作后，应再进一步学习和应用公司的规范。 建议学生在学习本规范的同时，花点时间阅读本规范的参考文献原文，特别是熟读本规范的参考文献之一的《“安全第一”的C语言编程规范》，深刻理解编程规范与程序安全、健壮、可靠、可读、可维护间的关系和作用，在学习和工作中养成良好的编程风格。 1 排版 1.1 严格采用阶梯层次组织程序代码 函数或过程的开始、结构的定义及循环、判断等语句中的代码都要采用缩进风格，case 语句下的情况处理语句也要遵从语句缩进要求。 程序块的分界符(如C/C++ 语言的大括号‘{’和‘}’)应各独占一行并且位于同一列，同时与引用它们的语句左对齐。在函数体的开始、类的定义、结构的定义、枚举的定义以及if 、for 、do 、while 、switch 、case 语句中的程序都要采用如上的缩进方式。 各层次缩进的风格采用TAB缩进(TAB宽度原则上使用系统默认值，TC使用8空格宽度，VC使用4空格宽度)。示例：
C#代码规范 1、前言 本文档定义了一些通用的代码规范和准则，一般情况下本文档适用于项目组所有项目，特殊情况下，如果客户有自己的代码规范，以客户的代码优先。 2、大小写约定 2.1、大小写样式，本文中将出现两种大小写样式，这里先分别定义： Pascal大小写 将标识符的首字母和后面连接的每个单词的首字母都大写。可以对三字符或更多字符的标识符使用Pascal大小写。例如：BackColor Camel大小写 标识符的首字母小写，而每个后面连接的单词的首字母都大写。例如：backColor 匈牙利命名法 基本原则是：变量名=属性+类型+对象描述。例如：lblName 2.2、标识符大小写规则 2.2.1、下表中列出常见的代码元素的样式规范和示例
2.2.2、除了遵循以上大小写约定外还需注意以下约定（除常量为特例）： ?如果标识符由多个单词组成，请不要在各单词之间使用分隔符，如下划线（“_”）或连字符（“-”）等。而应使用大小写来指示每个单词的开头。 ?所有公共的成员如：方法、属性，都应使用Pascal大小写样式 2.3、首缩写词的大小写规则 2.3.1、首字母缩写词 首字母缩写词是由术语或短语中各单词的首字母构成的单词。 例如，HTML是HypertextMarkupLanguage的首字母缩写。为了方便编码规范的实施，本文规定受字母缩写词必须至少为两个单词，正好为两个单词的首字母缩写词称其为“短型首字母缩写词”，两个单词以上的称其为“长型首字母缩写词”
2.3.2、单缩写词 单缩写词是一个单词的缩写。例如，ID是identifier的缩写。 注意：可在标识符中使用的两个缩写词是ID和OK。在采用Pascal大小写格式的标识符中，这两个缩写词的大小写形式应分别为Id和Ok。如果在采用大小写混合格式的标识符中将这两个缩写词用作首个单词，则它们的大小写形式应分别为id和ok。 2.3.3、首字母缩写词有以下大小写规则： 短型首字母缩写词在Pascal大小写样式中，两个字母都应大写。在Camel 大小写样式中，如果是首个单词，两个字母都应小写。例如： ?名为DBRate的属性是一个采用Pascal大小写格式的标识符，它使用短型首字母缩写词(DB)作为首个单词。 ?名为ioChannel的参数是一个采用大小写混合格式的标识符，它使用短型首字母缩写词(IO)作为首个单词。 长型首字母缩写词，在任何大小写样式中都视为一个单词。例如： ?名为XmlWriter的类是一个采用Pascal大小写格式的标识符，它使用长型首字母缩写词作为首个单词。 ?名为htmlReader的参数是一个采用大小写混合格式的标识符，它使用长型首字母缩写词作为首个单词。 2.3.4、复合词的大小写规则： 所有复合词在任何大小写样式中都视为一个完整单词。 例如，hashtable是一个紧凑格式的复合词，应将其视为一个单词并相应地确定大小写。如果采用Pascal大小写格式，则该复合词为Hashtable;如果采用大小写混合格式，则该复合词为hashtable。若要确定某个单词是否是紧凑格式的复合词，请查阅最新的词典。 2.3.5、区分大小写 大小写准则只是为了使标识符更易于阅读和辨认。不能将大小写规则用作避免库元素之间的命名冲突的手段。 3、通用命名约定
编码规范 1. 头文件编码规范 (2) 2. 函数编写规范 (2) 3. 标识符命名与定义 (2) 3.1通用命名规则 (2) 3.2 变量命名规则 (3) 3.3函数命名规则 (3) 3.4 宏的命名规则 (3) 4. 变量 (3) 5. 宏、常量 (4) 6. 质量保证 (4) 7. 程序效率 (5) 8. 注释 (5) 9. 排版与格式 (6) 10. 表达式 (7) 11. 代码编辑、编译 (7) 12. 安全性 (7) 13. 可读性 (7) 14. 可测性 (7) 15. 单元测试 (8) 16. 可移植性 (8)
1. 头文件编码规范 1. 禁止头文件循环依赖。 2. .c/.h文件不要包含用不到的头文件。 3. 禁止在头文件中定义变量。 4. 同一产品统一包含头文件排列方式。（如功能块排序、文件名升序、稳定度排序。） 5. 只能通过包含头文件的方式使用其他.c提供的接口，禁止在.c中通过extern的方式使用外部函数接口、变量。 2. 函数编写规范 1. 一个函数仅完成一件功能。 2. 重复代码应该尽可能提炼成函数。 3.为简单功能编写函数 4.函数的返回值要清楚、明了，让使用者不容易忽视错误情况。 5. 避免函数过长，新增函数不超过100行（非空非注释行）。 6. 避免函数的代码块嵌套过深，新增函数的代码块嵌套不超过4层。 7. 可重入函数应避免使用全局变量和禁止使用static变量。 8. 设计高扇入，合理扇出（小于7）的函数。 9. 废弃代码（没有被调用的函数和变量)要及时注释（有助于更好理解程序）。 10. 对所调用函数的错误返回码要仔细、全面地处理。 11. 函数不变参数使用const。 12. 函数应避免使用全局变量、静态局部变量和I/O操作，不可避免的地方应集中使用。 13. 函数的参数个数不超过5个。 14. 减少或禁止函数本身或函数间的递归调用 3. 标识符命名与定义 3.1通用命名规则 1. 标识符的命名要清晰、明了，有明确含义，同时使用完整的单词或大家基本可以理解的缩写，避免使人产生误解。 2. 除了常见的通用缩写以外，不使用单词缩写，不得使用汉语拼音。 示例： argument 可缩写为arg buffer 可缩写为buff clock 可缩写为clk command 可缩写为cmd compare 可缩写为cmp configuration 可缩写为cfg device 可缩写为dev error 可缩写为err hexadecimal 可缩写为hex increment 可缩写为inc initialize 可缩写为init maximum 可缩写为max message 可缩写为msg minimum 可缩写为min parameter 可缩写为para
1、头文件包含Includes 2、私有类型定义 Private typedef 3、私有定义Private define 4、私有宏定义 Private macro 5、私有变量 Private variables 6、私有函数原型Private function prototypes 7、私有函数Private functions 8、私有函数前注释 /****************************************************************************** * * Function Name : FSMC_NOR_Init * Description : Configures the FSMC and GPIOs to interface with the NOR memory. * This function must be called before any write/read operation * on the NOR. * Input : None * Output : None * Return : None ******************************************************************************* / 9、程序块采用缩进风格编写，缩进空格为4。 10、相对独立的程序块之间、变量说明之后必须加空行； 11、较长的字符（>80字符）要分成多行书写，长表达式要在低优先级操作符划分新行，操作符放在新行之首，新行要恰当缩进，保持排版整齐； 12、循环、判断等语句中若有较长的表达式或语句，则要进行适应的划分，长表达式要在低优先级操作符处划分新行，操作符放在新行之首; 13、若函数或过程中的参数较长，则要进行适当的划分。 14、不允许把多个短语句写在一行中，即一行只写一条语句。 15、if、for、do、while、case、switch、default等语句自占一行，且if、for、 do、while等语句的执行语句部分无论多少都要加括号{}。 16、对齐只使用空格键，不使用TAB键； 17、 函数或过程的开始、结构的定义及循环、判断等语句中的代码都要采用缩进风格，case 语句下的情况处理语句也要遵从语句缩进要求 18、 程序块的分界符（如C/C++语言的大括号‘{’和‘}’）应各独占一行并且位于同一 列，同时与引用它们的语句左对齐。在函数体的开始、类的定义、结构的定义、枚举的定义以 及if、for、do、while、switch、case语句中的程序都要采用如上的缩进方式。 19、 在两个以上的关键字、变量、常量进行对等操作时，它们之间的操作符之前、之后或
C语言编码规范 1．文件、函数规范 根据功能划分文件。文件名与主控函数名相同；主控函数必须放在最前面；函数的长度一般不宜超过150行；文件长度不宜超过500行。标准的文件头格式如下： 函数名： 功能： 调用函数：所涉及的主要功能函数 调用参数：必须详细说明 返回值： 编写时间： 修改时间：修改时包含此项 2．命名规范 ①函数命名规范 以便于理解为原则，由一个或多个单词或单词缩写组合而成，单词首字母大写。 如AddItem()，GetInt()，FxaUp() ②变量命名规范 由变量类型为前缀，加上函数命名规范组合而成。具体前缀命名方法如下：sh------short, i------int, l------long, c------char, f------float, d------double, p------pointer 字符串数组也使用p标志 静态变量名前用s标志 数组变量名前用stru标志 全局变量使用前缀g_标志 如：dBalance，fInterest，pName, sCustomer，struPersonWang, g_iOperNo 3．书写规范 ⑴对齐原则 同一层次的语句必须左对齐。“{”和“}”必须独占一行。 ⑵缩进原则 不同层次的语句必须遵从缩进原则，一般缩进四个字符为宜,TAB值设为4。 Case后的语句（简短注释语句除外）应另起一行，且须与“：”相接。 ⑶分行书写原则 当行超过屏幕上的行时，应分行书写。 ⑷注释符要求 单行注释符使用“//”，多行注释符使用“/*……*/”，注释符必须遵从前面3条原则，“/*”应与“*/”对齐。 4．语法规范
软件开发规范 在研究项目团队协作开发的情况下（这里的团队协作也适合于应用项目的开发），编程时应该强调的一个重要方面是程序的易读性，在保证软件速度等性能指标能满足用户需求的情况下，能让其他程序员容易读懂你所编写的程序。若研究项目小组的所有开发人员都遵循统一的、鲜明的一套编程风格，可以让协作者、后继者和自己一目了然，在很短的时间内看清楚程序结构，理解设计的思路，大大提高代码的可读性、可重用性、程序健壮性、可移植性、可维护性。 制定本编程规范的目的是为了提高软件开发效率及所开发软件的可维护性，提高软件的质量。本规范由程序风格、命名规范、注释规范、程序健壮性、可移植性、错误处理以及软件的模块化规范等部分组成。 本软件开发规范适合讨论C/C++程序设计。 1 文件结构 每个C++/C程序通常分为两个文件。一个文件用于保存程序的声明（declaration），称为头文件。另一个文件用于保存程序的实现（implementation），称为定义（definition）文件。 C++/C程序的头文件以“.h”为后缀，C程序的定义文件以“.c”为后缀，C++程序的定义文件通常以“.cpp”为后缀（也有一些系统以“.cc”或“.cxx”为后缀）。 文件信息声明 文件信息声明位于头文件和定义文件的开头（参见示例1-1），主要内容有：（1）版权信息； （2）文件名称，项目代码，摘要，参考文献； ？ （3）当前版本号，作者/修改者，完成日期； （4）版本历史信息； （5）主要函数描述。
.... 例如一个short*型的变量应该表示为pnStart； ☆【规则】全局变量用g_开头；例如一个全局的长型变量定义为g_lFileNum， 即：变量名＝g_＋变量类型＋变量的英文意思(或缩写)； ☆【规则】静态变量采用s_开头；例如一个静态的指针变量定义为s_plPrevInst， 即：变量名＝s_＋变量类型＋变量的英文意思(或缩写)；
c代码规范(总7页) -CAL-FENGHAI.-(YICAI)-Company One1 -CAL-本页仅作为文档封面，使用请直接删除
C# 代码规范 1、前言 本文档定义了一些通用的代码规范和准则，一般情况下本文档适用于项目组所有项目，特殊情况下，如果客户有自己的代码规范，以客户的代码优先。 2、大小写约定 2.1、大小写样式，本文中将出现两种大小写样式，这里先分别定义： Pascal大小写 将标识符的首字母和后面连接的每个单词的首字母都大写。可以对三字符或更多字符的标识符使用 Pascal 大小写。例如：BackColor Camel大小写 标识符的首字母小写，而每个后面连接的单词的首字母都大写。例如：backColor 匈牙利命名法 基本原则是：变量名=属性+类型+对象描述。例如：lblName 2.2、标识符大小写规则 2.2.1、下表中列出常见的代码元素的样式规范和示例 标识符规则示例 类Pascal AppDomain 枚举类型Pascal ErrorLevel 枚举值Pascal Warning 事件Pascal ValueChanging, ValueChanged 异常类Pascal WebException 只读的静态字段Pascal CurrentUser 接口Pascal IDisposable 方法Pascal ToString 命名空间Pascal 参数Camel typeName 属性Pascal Name 常量全大写MAXLENGTH, LENGTH_MAX Web或Win控件匈牙利txtName 2.2.2、除了遵循以上大小写约定外还需注意以下约定（除常量为特例）： 如果标识符由多个单词组成，请不要在各单词之间使用分隔符，如下划线（“_”）或连字符（“-”）等。而应使用大小写来指示每个单词的开头。 所有公共的成员如：方法、属性，都应使用Pascal大小写样式 2.3、首缩写词的大小写规则 2.3.1、首字母缩写词 首字母缩写词是由术语或短语中各单词的首字母构成的单词。 例如，HTML 是 Hypertext Markup Language 的首字母缩写。为了方便编码规范的实施，本文规定受字母缩写词必须至少为两个单词，正好为两个单词的首字母缩写词称其为“短型首字母缩写词”，两个单词以上的称其为“长型首字母缩写词” 2.3.2、单缩写词
如对您有帮助，请购买打赏，谢谢您！ C语言书写规范指南 第1章文件结构 每个C程序通常分为两个文件。一个文件用于保存程序的声明（declaration），称为头文件。另一个文件用于保存程序的实现（implementation），称为定义（definition）文件。 C程序的头文件以“.h”为后缀，C程序的定义文件以“.c”为后缀。 1.1版权和版本的声明 版权和版本的声明位于头文件和定义文件的开头（参见示例1-1），主要内容有： （1）版权信息。 （2）文件名称，标识符，摘要。 （3）当前版本号，作者/修改者，完成日期。 （4）版本历史信息。 /* *Copyright(c)2001,吉林大学物理学院无线电 *Allrightsreserved. * *文件名称：filename.h *文件标识： *摘要：简要描述本文件的内容 * *当前版本：1.1 *作者：输入作者（或修改者）名字 *完成日期：2007年7月20日 * *取代版本：1.0 *原作者：输入原作者（或修改者）名字 *完成日期：2007年5月10日 */ 示例1-1版权和版本的声明 1.2头文件的结构 头文件由三部分内容组成： （1）头文件开头处的版权和版本声明（参见示例1-1）。 （2）预处理块。 （3）函数和类结构声明等。 假设头文件名称为SCL_SPI.h，头文件的结构参见示例1-2。 【规则1-2-1】为了防止头文件被重复引用，应当用#ifndef/#define/#endif结构产生预处理块。 【规则1-2-2】用#include
int fun (int x , int y , int z ){ …… return 0; }if (a >= b && b >= c && c >= d && ...... ) if (p !- NULL ) delete p ;x += y ; val = (mark << 3); void fun (int x , int y , int z ) for (i = 0; i < 10; ++i ) ps :void fun (int x , int y )if (x == y ) i ++; char *p = &temp ; tmp = p ->size ; tmp = q .val ; a = (p +q ) * (m -n ) / (i +j ); 代码规范 １、布局和风格 １、总体布局 ２、空格 总体目标：准确表现代码的逻辑结构；改善可读性；经得起修改。 采用纯块布局，即 “｛” “｝” 垂直对齐； 缩进为４字节，巧用Ｔａｂ键。 对于复杂的表达式，将条件分格在几行； 一行代码宽度应不超过８０个字符，对于较长的语句，应该分行书写，增加代码的可读性。每行仅写一条语句 有需要空格的地方： 双目运算符两侧，需要留有空格。如“＝”， “＋＝”， “＞＝“， ”＋“， ”＆＆“等函数参数之间逗号后； ｆｏｒ语句的分号后面要留有空格 不留空格的地方： 函数名紧跟左括号； 左空号右边和右括号左边不用空格 定义变量后最好加上空行；函数与函数之间最好加上空行； 对于表达式较长的语句，适当去掉空格 ［］，－＞， ．，等操作符前后不加空格 单目运算符前后不加空格，如”！“， ”＆”，“＋＋”等
C语言程序代码编写规范 （初级程序员讨论版） 前言 一个好的程序编写规范是编写高质量程序的保证。清晰、规范的源程序不仅仅是方便阅读，更重要的是能够便于检查错误，提高调试效率，从而最终保证软件的质量和可维护性。 说明 此文挡还在完善改进中，如有不足，欢迎指正。 本文档主要适用于刚刚开始接触编程的初学者。 对于具有一定工程项目开发经验的程序员，建议学习C语言程序代码编写规范 —高级版。 目录 1代码书写规范 2注释书写规范 3命名规范
内容 1 代码书写规范 函数定义 每个函数的定义和说明应该从第1列开始书写。函数名（包括参数表）和函数体的花括号（“{”和“}”）应该各占一行。在函数体结尾的括号（“}”）后面应该加上注释，注释中应该包括函数名，这样比较方便进行括号配对检查，也可以清晰地看出来函数是否结束。 范例1：函数的声明 void matMyFunction(int n) { …… } /* matMyFunction*/ 空格的使用 使用空格分割所有演算符号和操作数。 这条规则的例外是“->”,““.”, “()”和“[]”，这些操作符和操作数之间不空格。 当需要把一个程序行的内容分成几行写时，操作符号应该放在行末，而不是下一行的开头。 缩进的设置 代码书写应该遵从结构化的要求，采用缩进的格式。最小缩进量为4个空格，整个文件内部应该统一，不要混用Tab键和4个空格这两种情况，因为不同的编辑器对Tab键的处理方法不同。 折行的使用 每行的长度不要超过80个字符，当程序行太长时，应该分行书写。 分行时应该按照自然的逻辑关系进行，例如：不要把一个简单的逻辑判断写在 两行上。 分行后的缩进应该按照程序的逻辑关系进行对齐。例如：参数表折行后，下面 的行应该在参数表左括号的下方。 范例2：折行的格式
编码规 1. 头文件编码规 (2) 2. 函数编写规 (2) 3. 标识符命名与定义 (2) 3.1通用命名规则 (2) 3.2 变量命名规则 (3) 3.3函数命名规则 (3) 3.4 宏的命名规则 (3) 4. 变量 (3) 5. 宏、常量 (4) 6. 质量保证 (4) 7. 程序效率 (5) 8. 注释 (5) 9. 排版与格式 (6) 10. 表达式 (7) 11. 代码编辑、编译 (7) 12. 安全性 (7) 13. 可读性 (7) 14. 可测性 (7) 15. 单元测试 (8) 16. 可移植性 (8)
1. 头文件编码规 1. 禁止头文件循环依赖。 2. .c/.h文件不要包含用不到的头文件。 3. 禁止在头文件中定义变量。 4. 同一产品统一包含头文件排列方式。（如功能块排序、文件名升序、稳定度排序。） 5. 只能通过包含头文件的方式使用其他.c提供的接口，禁止在.c过extern的方式使用外部函数接口、变量。 2. 函数编写规 1. 一个函数仅完成一件功能。 2. 重复代码应该尽可能提炼成函数。 3.为简单功能编写函数 4.函数的返回值要清楚、明了，让使用者不容易忽视错误情况。 5. 避免函数过长，新增函数不超过100行（非空非注释行）。 6. 避免函数的代码块嵌套过深，新增函数的代码块嵌套不超过4层。 7. 可重入函数应避免使用全局变量和禁止使用static变量。 8. 设计高扇入，合理扇出（小于7）的函数。 9. 废弃代码（没有被调用的函数和变量)要及时注释（有助于更好理解程序）。 10. 对所调用函数的错误返回码要仔细、全面地处理。 11. 函数不变参数使用const。 12. 函数应避免使用全局变量、静态局部变量和I/O操作，不可避免的地方应集中使用。 13. 函数的参数个数不超过5个。 14. 减少或禁止函数本身或函数间的递归调用 3. 标识符命名与定义 3.1通用命名规则 1. 标识符的命名要清晰、明了，有明确含义，同时使用完整的单词或大家基本可以理解的缩写，避免使人产生误解。 2. 除了常见的通用缩写以外，不使用单词缩写，不得使用汉语拼音。 示例： argument 可缩写为arg buffer 可缩写为buff clock 可缩写为clk command 可缩写为cmd compare 可缩写为cmp configuration 可缩写为cfg device 可缩写为dev error 可缩写为err hexadecimal 可缩写为hex increment 可缩写为inc initialize 可缩写为init maximum 可缩写为max message 可缩写为msg minimum 可缩写为min parameter 可缩写为para
C语言格式书写规范 Document number：NOCG-YUNOO-BUYTT-UU986-1986UT
C语言书写规范指南 第1章文件结构 每个C程序通常分为两个文件。一个文件用于保存程序的声明（declaration），称为头文件。另一个文件用于保存程序的实现（implementation），称为定义（definition）文件。 C程序的头文件以“.h”为后缀，C程序的定义文件以“.c”为后缀。 版权和版本的声明 版权和版本的声明位于头文件和定义文件的开头（参见示例1-1），主要内容有： （1）版权信息。 （2）文件名称，标识符，摘要。 （3）当前版本号，作者/修改者，完成日期。 （4）版本历史信息。 /* *Copyright(c)2001,吉林大学物理学院无线电 *Allrightsreserved. * *文件名称： *文件标识： *摘要：简要描述本文件的内容 * *当前版本： *作者：输入作者（或修改者）名字 *完成日期：2007年7月20日 * *取代版本： *原作者：输入原作者（或修改者）名字 *完成日期：2007年5月10日 */ 示例1-1版权和版本的声明 头文件的结构 头文件由三部分内容组成： （1）头文件开头处的版权和版本声明（参见示例1-1）。 （2）预处理块。 （3）函数和类结构声明等。
假设头文件名称为，头文件的结构参见示例1-2。 【规则1-2-1】为了防止头文件被重复引用，应当用#ifndef/#define/#endif结构产生预处理块。 【规则1-2-2】用#include <>格式来引用标准库的头文件（编译器将从标准库目录开始搜索）。 【规则1-2-3】用#include “”格式来引用非标准库的头文件（编译器将从用户的工作目录开始搜索）。 【规则1-2-4】#include后面使用TAB键控制排版。 【规则1-2-5】头文件中只存放“声明”而不存放“定义” 【规则1-2-6】全局变量在头文件中声明,在.c文件中定义 .hexternintvalue;声明。 .cintvalue=0x10;定义。 【规则1-2-7】局部变量在.c中定义(static)unsignedintvalue;定义。 、“->”这类操作符前后不加空格。 【建议2-3-1】对于表达式比较长的for语句和if语句，为了紧凑起见可以适当
DKBA 华为技术有限公司内部技术规范 DKBA 2826-2011.5 C语言编程规范 2011年5月9日发布 2011年5月9日实施 华为技术有限公司 Huawei Technologies Co., Ltd. 版权所有侵权必究 All rights reserved
修订声明Revision declaration 本规范拟制与解释部门： 本规范的相关系列规范或文件： 相关国际规范或文件一致性： 替代或作废的其它规范或文件： 相关规范或文件的相互关系：
目录Table of Contents 0规范制订说明 (5) 0.1前言 (5) 0.2代码总体原则 (5) 0.3规范实施、解释 (6) 0.4术语定义 (6) 1头文件 (6) 2函数 (12) 3标识符命名与定义 (21) 3.1通用命名规则 (21) 3.2文件命名规则 (23) 3.3变量命名规则 (23) 3.4函数命名规则 (24) 3.5宏的命名规则 (24) 4变量 (25) 5宏、常量 (28) 6质量保证 (32) 7程序效率 (36) 8注释 (39) 9排版与格式 (44) 10表达式 (46) 11代码编辑、编译 (49) 12可测性 (50) 13安全性 (51) 13.1字符串操作安全 (51) 13.2整数安全 (52) 13.3格式化输出安全 (56) 13.4文件I/O安全 (57) 13.5其它 (59) 14单元测试 (59) 15可移植性 (60) 16业界编程规范 (60)
C语言编程规范 范围: 本规范适用于公司内使用C语言编码的所有软件。本规范自发布之日起生效，以后新编写的和修改的代码应遵守本规范。 简介： 本规范制定了编写C语言程序的基本原则、规则和建议。从代码的清晰、简洁、可测试、安全、程序效率、可移植各个方面对C语言编程作出了具体指导。
第一章 C语言编程规范 C语言编程规范使用于所有的平台程序和应用程序开发。 C语言编程规范分为编程环境，命名规范，内容排列，书写格式，注释规范和程序修改等六部分内容。 具体格式参见《C头文件样本》和《C源程序样本》。 1.1编程环境。 包括目录及其权限设置，makefile使用两部分内容。 1.1.1目录设置。 进行C语言程序开发，一般设置如下六个目录。 各目录及其文件的权限一般使用系统确省，也可根据具体需要进行设置。 ●SRC：存放C源程序文件（*.c），数据库语言程序文件（如*.ec）。 ●INCL：存放C头文件（*.h）。 ●OBJ：存放目标文件（*.o）。 ●LIB：存放一般库文件（*.a），动态链接库文件（如*.so）。 ●BIN：存放可执行文件，SHELL文件。 ●BAK：源程序和头文件备份目录（以日期做文件后缀，如*.990806）。 1.1.2Makefile使用。 Makefile存放在SRC目录下，控制程序的编译与连接，库的生成与更新。 Makefile的定义内容和排列顺序为： ●编程环境目录宏定义。 ●C头文件搜索目录宏定义。 ●库文件搜索目录宏定义。 ●编译控制参数宏定义。 ●一般程序编译与连接方法。
●全部程序编译与连接列表。 ●复杂程序（多个.o）连接方法。 1.2命名规范。 包括源程序文件，头文件，目标文件，库文件，执行文件，宏定义，变量，结构，结构元素，函数等十类命名规范。 各类命名规范均基于《系统基本数据名称集》。 1.2.1源程序文件。 ●一般形式：AAABCCCC。不得超过8个字符。 ●AAA（2或3个字符）：表示该源程序所属的系统（如btp，feb等）。 ●B：一般情况可省略。当多个源程序文件属于同一功能的分支程序，用来 表示源程序文件的功能类型（如m表示主程序，i表示输入，o表示输出等）。 ●CCCC：表示源程序的功能。 1.2.2头文件。 ●一般形式：AAACCCCC。不得超过8个字符。 ●AAA（2或3个字符）：表示该头文件所属的系统（如btp，feb等）。 ●CCCCC：表示头文件的功能。 ●如头文件只被某一个源程序文件使用，名称应和源程序文件名称相同。 1.2.3目标文件。 ●一般的，应和源程序文件名称相同。 ●如和源程序文件名称不同，须得到主设计人员和部门主管同意。 1.2.4库文件。 ●库文件的名称一般在系统总体设计时即确定。 ●一般形式：libAAACCCC。 ●前三个字符一般固定为lib。 ●AAA（2或3个字符）：表示该库文件所属的系统（如btp，feb等）。
C语言编码规范
文档修改记录 版本版本日期说明编写者审核者V0.1吕晓敏
1排版规则 1)程序应采用缩进风格编写，每层缩进使用一个制表位（TAB），类定义、方法都应顶 格书写； 2)源程序建议使用英文书写，尽量不含有中文。每行不超过80字符。对于较长的语 句（>80字符）要分成多行书写，长表达式要在低优先级操作符处划分新行，操作符放在新行之首，划分出的新行要进行适当的缩进，使排版整齐，语句可读；循环、判断等语句中若有较长的表达式或语句，则要进行适应的划分； 3)左花括号要另起一行，不能跟在上一行的行末； 4)一个变量定义占一行，一个语句占一行； 5)对独立的程序块之间、变量说明之后必须加空行； 6)在结构成员赋值等情况，等号对齐，最少留一个空格； 7)若函数或过程中的参数较长，则要进行适当的划分。 8)形参的排序风格： 最常使用的参数放在第一位； 输入参数列表应放在输出参数列表的左边； 将通用的参数放在特殊的参数的左边。 2命名规范 2.1应用程序的命名 “系统简称”+模块名称 2.2子模块的命名 每个子模块的名字应该由描述模块功能的1-3以单词组成。每个单词的首字母应大写。在这些单词中可以使用一些较通用的缩写。 2.3变量的命名 变量的命名的基本原则是使得变量的含义能够从名字中直接理解。可以用多个英文单词拼写而成，每个英文单词的首字母要大写，其中英文单词有缩写的可用缩写；变量的前缀表示该变量的类型；对于作用域跨越10行以上的变量名称不能少于4个字符，除循环变量，累加变量外不得使用I、j、k等名称的变量。变量分为取全局变量和局部变量，对于全局变量以加前缀“g_”来区分。 使用有意义的英语单词,使用大小写分隔,每个单词的第一个字母为大写标识符种类书写规范示例 函数/过程名/变量一般标识符CheckButtonStates 宏标识符大写标识符SALES_TAX 类型定义‘T’+一般标识符TMyType 类标识符‘C’+一般标识符CEditBox 结构标识符‘S’+一般标识符SMyStructure 联合标识符‘U’+一般标识符UMyUnion
C# 代码规范 1、前言 本文档定义了一些通用的代码规范和准则，一般情况下本文档适用于项目组所有项目，特殊情况下，如果客户有自己的代码规范，以客户的代码优先。 2、大小写约定 2.1、大小写样式，本文中将出现两种大小写样式，这里先分别定义： Pascal大小写 将标识符的首字母和后面连接的每个单词的首字母都大写。可以对三字符或更多字符的标识符使用 Pascal 大小写。例如：BackColor Camel大小写 标识符的首字母小写，而每个后面连接的单词的首字母都大写。例如：backColor 匈牙利命名法 基本原则是：变量名=属性+类型+对象描述。例如：lblName 2.2、标识符大小写规则 2.2.1、下表中列出常见的代码元素的样式规范和示例
枚举类型Pascal ErrorLevel 枚举值Pascal Warning 事件Pascal ValueChanging, ValueChanged 异常类Pascal WebException 只读的静态字段Pascal CurrentUser 接口Pascal IDisposable 方法Pascal ToString 命名空间Pascal System.Data 参数Camel typeName 属性Pascal Name 常量全大写MAXLENGTH, LENGTH_MAX Web或Win控件匈牙利txtName 2.2.2、除了遵循以上大小写约定外还需注意以下约定（除常量为特例）： 如果标识符由多个单词组成，请不要在各单词之间使用分隔符，如下划线（“_”）或连字符（“-”）等。而应使用大小写来指示每个单词的开头。 所有公共的成员如：方法、属性，都应使用Pascal大小写样式 2.3、首缩写词的大小写规则
0. 说明 本规范尚在完善中，随时更新。 代码风格以增强程序可读性和可维护性为目标，并非金科玉律。在满足可读性和可维护性的前提下，可以适当灵活。参考：高质量C++/C 编程指南 1. 注释 1.程序中必须有清晰的注释； 2.程序头部要有程序整体说明信息； 3.每个函数（main除外）都要有注释说明该函数的功能，及其参数和返回值的意义； 4.每个变量都要有注释说明其用途(for 循环中的下标除外)； 5.代码中要有适当的注释说明代码段的功能。 2. 缩进 1.缩进的宽度为4个字符，鼓励用空格缩进, tab亦可(但尽量避免两者混用)； 2.凡函数、if、while、for、do-while、switch等都要使用缩进。 3. 标识符命名 1.凡标识符的命名要尽量能直观反映该标识符的功能（如做到这一点，可免去注释说明）； 2.标识符用英文命名，不可用汉语拼音； 3.变量命名采用“variable_name”的形式； 4.函数命名采用“FunctionName”的形式； 5.宏、常量、枚举的命名采用“MACRO_NAME”的形式。 4. 空行及空格 1.以增强可读性为目标，适当使用空行和空格； 2.不可出现连续的两个及两个以上的空行； 3.代码功能段之间用空行分隔； 4.不在行尾的每个逗号和分号后要有一个空格； 5.一般每个运算符前后都要有一个空格； 6.if, while, for, do, switch 和判断条件之间要有一个空格。 5. 其它 1.左大括号“{”后不可出现代码； 2.右大括号“}”前不可出现代码； 3.每行只能写一条代码，且该行代码总长不可超过80个字符； 4.常数应定义为宏、枚举或常量； 5.……