c,c++代码格式规范
c,c++代码格式规范
第一章 原则
使代码易于管理的方法之一是增强代码一致性，让别人可以读懂你的代码是很重要的，保持统一编程风格意味着可以轻松根据“模式匹配”规则推断各种符号的含义。创建通用的、必需的习惯用语和模式可以使代码更加容易理解。虽然在某些情况下改变一些编程风格可能会是好的选择，但我们还是应该遵循一致性原则，尽量不这样去做。
关键在于保持一致。
第二章 排版
2.1 空行
【规则2-1-1】在每个函数、结构体、枚举、类定义结束之后都要加空行。
【规则2-1-2】在一个函数体内，逻辑密切相关的语句之间不加空行，其它地方应加空行分隔。
struct st1
{
…
};
// 空行
enum
{
…
};
// 空行
void Function1(…)
{
…
}
// 空行
void Function2(…)
{
…
} // 空行
while (condition)
{
statement1;
// 空行
if (condition)
{
statement2;
}
else
{
statement3;
}
// 空行
statement4;
}
函数之间的空行 函数内部的空行
【规则2-1-3】相对独立的程序块之间、变量说明之后必须加空行。
if (!is_lock_card_succ)
{
… // program code
}
GetLockPhoneInfo(&st_lock_phone_info); if (!is_lock_card_succ)
{
… // program code
}
//空行
GetLockPhoneInfo(&st_lock_phone_info);
不规范代码 规范代码
2.2 代码行
【规则2-2-1】一行代码只做一件事情，如只定义一个变量，或只写一条语句。这样的代码容易阅读，并且方便于写注释。
【规则2-2-2】if、for、while、do等语句自占一行，执行语句不得紧跟其后。不论执行语句有多少都要加{}。这样可以防止书写失误。
int width, height, depth;// 宽度高度深度
int width; // 宽度
int height; // 高度
int 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 代码行内的空格
说明：空格的目的在于更清晰的代码。
【规则2-3-1】关键字之后要留空格。const、static等关键字之后至少要留一个空格，否则无法辨析关键字；if、for、while、switch等关键字之后应留一个空格再跟左括号‘(’，以突出关键字。
【规则2-3-2】函数名之后不要留空格，紧跟左括号‘(’，以与关键字区别。
【规则2-3-3】‘(’向后紧跟，‘)’、‘,’、‘;’向前紧跟，紧跟处不留空格。
【规则2-3-4】‘,’之后要留空格，如Function(x, y, z)。如果‘;’不是一行的结束符号，其后要留空格，如for (initialization; condition; update)。
【规则2-3-5】赋值操作符、比较操作符、算术操作符、逻辑操作符、位域操作符，如“=”、“+=” “>=”、“<=”、“+”、“*”、“%”、“&&”、“||”、“<<”,“^”等二元操作符的前后应当加一个空格。
【规则2-3-6】一元操作符如“!”、“~”、“++”、“–”、“&”（地址运算符）等前后不加空格。
【规则2-3-7】象“［］”、“.”、“->”这类操作符前后不加空格。
【建议2-3-1】对于表达式比较长的for语句和if语句，为了紧凑起见可以适当地去掉一些空格，如for (i=0; i<10; i++)和if ((a<=b) && (c<=d))
void Func1(int x, int y, int z); void Func1 (int x,int y,int z);
if (year >= 2000) if(year>=2000)
if ((a>=b) && (c<=d))
if ((a >= b) && (c <= d)) 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;
i++;
int *x = &y; i ++;
int * x = & y;
array[5] = 0;
a.Function();
b->Function(); array [ 5 ] = 0;
a . Function();
b -> Function();
良好风格 不良风格
2.4 对齐缩进
【规则2-4-1】程序块要采用缩进风格编写。
【规则2-4-2】对齐使用TAB键，TAB键宽度设置为4个空格。
说明：应注意使用不同编辑器时，TAB键设置不同造成的排版不同；应注意某些编辑器在识别、显示TAB键上存在问题；最终排版应以在项目的主代码编辑器（如VC、Source Insight等）中显示一致统一、整洁清晰为准。
Source Insight中设置：
Options->Doucument Options->“Tab Width:4”
【规则2-4-3】函数或过程的开始、结构的定义及循环、判断等语句中的代码都要采用缩进风格，case语句下的情况处理语句也要遵从语句缩进要求。
【规则2-4-4】程序块的分界符（如‘{’和‘}’）应各独占一行并且位于同一列，同时与引用它们的语句左对齐。在函数体的开始、类的定义、结构的定义、枚举的定义以及if、for、do、while、switch、case语句中的程序都要采用如上的缩进方式。
for (…) {
… // program code
} for (…)
{
… // program code
}
if (…)
{
… // program code
}
if (…)
{
… // program code
}
void example_fun( void )
{
… // program code
} void example_fun( void )
{
… // program code
}
不规范代码 规范代码
【规则2-4-5】预处理指令不需要缩进，总是从行首开始。即使预处理指令位于缩进代码块中，指令也应从行首开始。
// 良好风格：预处理指令均从行首开始
if (lopsided_score)
{
#if DISASTER_PENDING // Correct – Starts at beginning of line
DropEverything();
#if NOTIFY
NotifyClient();
#endif
#endif
BackToNormal();
}
// 不良风格：缩进的预处理指令
if (lopsided_score)
{
#if DISASTER_PENDING // Wrong! The “#if” should be at beginning of line
DropEverything();
#endif // Wrong! Do not indent “#endif”
BackToNormal();
}
2.5 长行拆分
【规则2-5-1】代码行最大长度宜控制在100至110个字符以内。代码行不要过长，否则眼睛看不过来，也不便于打印。
【规则2-5-2】较长的语句（>110字符）要分成多行书写；长表达式要在低优先级操作符处拆分成新行，操作符放在新行之首（以便突出操作符）。拆分出的新行要进行适当的缩进，使排版整齐，语句可读。
【规则2-5-3】循环、判断等语句中若有较长的表达式或语句，则要进行适应的划分. 长表达式要在低优先级操作符处划分新行，操作符放在新行之首。
【规则2-5-4】若函数或过程中的参数较长，则要进行适当的划分。
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();
}
report_or_not_flag = ((taskno < MAX_ACT_TASK_NUMBER)
&& (n7stat_stat_item_valid (stat_item))
&& (act_task_table[taskno].result_data != 0));
n7stat_str_compare((BYTE *) & stat_object,
(BYTE *) & (act_task_table[taskno].stat_object),
sizeof (_STAT_OBJECT));
长行的拆分
第三章 注释
3.1 通用规则
【规则3-1-1】一般情况，需要保证程序有一定的注释。必须保证关键的函数、流程、类型定义、变量等有相应注释说明。
说明：注释的原则是有助于对程序的阅读理解，在该加的地方都加了，注释不宜太多也不能太少，注释语言必须准确、易懂。
【规则3-1-2】注释应当准确、易懂，防止注释有二义性。
说明：错误的注释不但无益反而有害。
【规则3-1-3】除非能使用准确的英文表达，则使用中文注释。
【规则3-1-4】避免在注释中使用缩写，特别是非常用缩写。
说明：在使用缩写时或之前，应对缩写进行必要的说明。
【规则3-1-5】需要为代码中使用的缩写增加注释,文件引入的新缩写必须在文件头部加以说明。
【规则3-1-6】通过对函数或过程、变量、结构等正确的命名以及合理地组织代码的结构，使代码成为自注释的。
说明：清晰准确的函数、变量等的命名，可增加代码可读性，并减少不必要的注释。
【规则3-1-7】注释格式尽量统一。建议使用//进行注释，多行注释可使用“/* …… */”。
3.2 文件注释
【规则3-2】源文件（包含.h头文件、.c源文件及各种脚本文件等）头部应进行注释，应列出：版权说明、文件名、文件目的/功能，作者、创建日期等；如果源文件引入了新的缩写，则必须在文件头部注释说明。
文件注释格式定义如下（可以不局限于该格式中定义的内容，但必须包含该格式中定义的内容）：
/************************************************************
** Copyright © 2010-2011, XXX Co. Ltd.
** All rights reserved.
**
** FileName: // 文件名称
** Description: // 文件描述
** Author: // 作者
** Date: // 创建时间
** Others: // 其它说明
***********************************************************/
/************************************************************
Abbreviation: // 如果文件引入了新的缩写，则必须在此处加以说明
***********************************************************/
举例如下：
/************************************************************
** Copyright © 2010-2011, XXX Co. Ltd.
** All rights reserved.
**
** FileName: starlib_nvset.h
** Description: NV参数配置源文件
** Author: zc
** Date: 2010/4/13
** Others:
***********************************************************/
/************************************************************
Abbreviation:
NCM: Net Choose Menu 网络选择菜单
VBC: Voice Broadcast 语音播报
***********************************************************/
3.3 函数注释
【规则3-3】函数头部应进行注释，需要列出函数的功能、参数、返回值等。
函数注释格式定义如下（可以不局限于该格式中定义的内容，但必须包含该格式中定义的内容）：
//
// Function: // 函数名称
// Description: // 函数功能描述
// Param: // 参数说明，包括参数的作用、取值范围等，格式如下：
// param1: 输入输出类型[IN/OUT/INOUT] 说明
// param2: 输入输出类型[IN/OUT/INOUT] 说明
// …
// Return: // 函数返回值说明
// Others: // 其它说明
// Author: // 作者
//
举例如下：
//
// Function: StarLib_SetIdleNetIconType
// Description: 设置待机界面网络图标
// PARAM: icon: [IN] 待机界面网络图标
// Return: 设置成功 = STARLIB_TRUE
// 设置失败 = STARLIB_FALSE
// Others:
// Author: zc
//
3.4 数据注释
【规则3-4-1】对于所有有物理含义的变量、常量，如果其命名不是充分自注释的，在声明时都必须加以注释，说明其物理含义。变量、常量、宏的注释应放在其上方相邻位置或右方。
// active statistic task number
#define MAX_ACT_TASK_NUMBER 1000
#define MAX_ACT_TASK_NUMBER 1000 // active statistic task number
【规则3-4-2】数据结构声明(包括结构体、枚举、类等)，如果其命名不是充分自注释的，必须加以注释。对数据结构的注释应放在其上方相邻位置；对结构中每个域的注释放在该域的右方。
// sccp interface with sccp user primitive message name
enum SCCP_USER_PRIMITIVE
{
N_UNITDATA_IND, // sccp notify sccp user unit data come
N_NOTICE_IND, /* sccp notify user the No.7 network can not
transmission this message*/
N_UNITDATA_REQ, // sccp user’s unit data transmission request
};
【规则3-4-3】全局变量必须有注释，包括对其功能、取值、及其他注意事项等的说明。
//标志是否通过锁卡流程；TURE = 通过锁卡流程，FALSE = 锁卡流程失败
PUBLIC BOOLEAN g_isLockCardPass = FALSE;
3.5 代码注释
【规则3-5-1】边写代码边注释，修改代码同时修改相应的注释，以保证注释与代码的一致性。不再有用的注释要删除！
【规则3-5-2】如果代码本来就是清楚的，则不必加注释。
i++; // i 加 1，多余的注释
【规则3-5-3】在代码的功能、意图层次上进行注释，提供有用、额外的信息。
// if receive_flag is TRUE
if (receive_flag) // if mtp receive a message from links
if (receive_flag)
无用注释 有用注释
【规则3-5-4】注释应与其描述的代码相邻。对语句块的注释必须放在语句块上方；对单条语句、变量定义的注释可以放在上方或右方（建议放在右方）；注释不可放在下方。
//get replicate sub system index and net indicator
repssn_ind = ssn_data[index].repssn_index;
repssn_ni = ssn_data[index].ni; 不良写法一
repssn_ind = ssn_data[index].repssn_index;
repssn_ni = ssn_data[index].ni;
//get replicate sub system index and net indicator 不良写法二
// get replicate sub system index and net indicator
repssn_ind = ssn_data[index].repssn_index;
repssn_ni = ssn_data[index].ni; 良好的写法
【规则3-5-5】如果注释放在上方，则将注释与其上面的代码用空行隔开。
// code one comments
program code one
// code two comments
program code two //code one comments
program code one
// code two comments
program code two
过于紧凑 良好写法
【规则3-5-6】避免在一行代码或表达式的中间插入注释。
说明：除非必要，不应在代码或表达中间插入注释，否则容易使代码可理解性变差。
【规则3-5-7】对于switch语句下的case语句，如果因为特殊情况需要处理完一个case后进入下一个case处理，必须在该case语句处理完、下一个case语句前加上明确的注释。
说明：这样比较清楚程序编写者的意图，有效防止无故遗漏break语句。
case CMD_A:
ProcessA();
break;
case CMD_B:
ProcessB ();
// 跳转到case CMD_C
case CMD_C:
ProcessC();
break;
【规则3-5-8】注释与所描述内容进行同样的缩排。
说明：可使程序排版整齐，并方便注释的阅读与理解。
void example_fun( void )
{
//code one comments
CodeBlock One
//code two comments
CodeBlock Two
} void example_fun( void )
{
// code one comments
CodeBlock One
// code two comments
CodeBlock Two
}
不好的注释缩排 良好的注释缩排
第四章 命名
4.1 通用命名规则
【规则4-1-1】标识符的命名要清晰明了，有明确含义；命名应具有描述性；一般而言，类型和变量应是名词，函数应是“命令性”动词；
int cnt; //计数器——名词
【规则4-1-2】命名应使用使用完整的单词或大家可以理解的缩写，避免使人产生误解；如使用特殊约定或缩写，要有注释说明，可参见【规则3-3】；需注意避免过度缩写。
//良好命名
int numError;
int numConnections;
NET_TYPE StarLib_GetNetWorkType(); //过度缩写
int nerr;
int nconns;
NET_TYPE StarLib_GetNWType();
4.2 变量命名
【规则4-2-1】采用骆驼命名法，局部变量、全局变量、参数变量、成员变量，变量名第一个单词以小写字母开始，第二个单词的首字母大写。
良好的命名：
int curNum;
int a[10];
char s[10];
int getNumber(int x)
{
return a[x];
}
4.3 常量命名
【规则4-3-1】常量名全部字母大写。
const float PI = 3.14;
const int VAL_MIN = 1;
第五章 杂项
【规则5-1】所有变量定义时必须进行显式初始化。
即使是全局变量、静态变量，同样要在定义进行显式初始化。
//不合规范的做法
static int a;
int b;
//规范的做法
static int a = 0;
int b = 0;
ST_A st = {0};
【规则5-2】为了防止头文件被重复引用（会导致类型重定义错），应当增加包含岗哨——使用#ifndef/#define/#endif结构产生预处理块。
#ifndef STAR_LIB_H // 防止StarLib.h被重复引用
#define STAR_LIB_H
…
#endif //_STAR_LIB_H_s
【规则5-3】定义函数、全局变量时，必须显式说明其作用域。
由于C语言中没有对应的关键字，可使用如下处理方式：
#define PUBLIC
#define LOCAL static
然后LOCAL代表作用域为所在文件，PUBLIC代表作用域为所有文件。
（为方便理解，此处使用了“作用域”一词；但应知道，实际上声明的是函数/变量的连接属性——内部连接internal linkage/外部连接external linkage）。
#define PUBLIC
#define LOCAL static
LOCAL U32 local_variable = 0;
PUBLIC U32 global_variable = 0;
LOCAL void local_func(void)
{
…
}
PUBLIC void global_func(void)
{
…
}
c,c++代码格式规范相关推荐
- C/C++代码格式规范（一）
在写代码的时候,通常需要遵循一定的代码格式规范,本文针对自己做项目以及所接触的代码形式,同时也参考红帽rpm源码和谷歌代码规范,总结一下写代码时的编程规范,当然这不是硬性规定,许多地方可以根据自己的喜 ...
- C/C++代码格式规范（二）
上一篇文章总结了变量.循环/条件语句的命名以及编写规范,这篇文章来说下函数的代码格式规范. 一.函数格式规范 函数左大括号可以单独一行或者与函数名.参数等在同一行: 如果左大括号与函数名参数等在同一行 ...
- python 代码格式规范脚本_Python编码规范
Python自动化测试代码编码规范 一.适用范围: 本规则基础为Python标准PEP8,在此基础上加了我司测试部编码规范,适用于测试部所有Python脚本编写是采用的规则. 二.编码: 所有的 Py ...
- Alibaba代码规范插件、FindBugs插件安装及详解，IDEA插件安装，代码规范，代码查错，代码格式规范
这是帮助开发者规范代码,培养优良的编码习惯的两个IDEA插件
- 【Java】代码格式规范
文章目录 1. 初级阶段 1. 初级阶段 类和方法的注释,要采用"文档注释"的方法,即借助javadoc工具. 非javadoc的注释,即单行注释.多行注释,一般是给代码的维护者来 ...
- PPT里对指定三角形的三条边作垂直平分线的VBA代码，要求代码格式规范
下面是一个示例代码: Sub 画垂直平分线()Dim shp As Shape Dim x1 As Single, y1 As Single Dim x2 As Single, y2 As Singl ...
- Python学习笔记之几点代码格式要求
1.缩进:通常我们都是用Tab制表符进行代码缩进,但是标准来说是要用4个空格进行缩进,如果代码工具可以设置按Tab自动转换为4个空格,那就设置一下吧,想想之前写的代码没有用4个空格,代码规范很重要,在 ...
- java dao层编写及注释_JAVA代码注释规范
2. 班级: 班级的目的,即班级完成的功能,以及班级的创建时间和作者姓名:当多个人一次编辑或修改同一个班级时, 作者姓名中应出现多个姓名: 3. 接口: 在满足类注释的基础上,接口注释应包含设置接口的 ...
- Java开发规范之代码格式篇（上）
在程序员的世界里有两件最讨厌的事情,第一件事情是讨厌写代码注释,第二件事情是讨厌看别人的代码不写注释.虽然这只是个段子,但也反映了当下很多程序员的心声.下面简单介绍下代码规范的重要性,第一,规范的代码 ...
最新文章
- U3D非常诡异的【结构体引用】现象-个例
- 基于 abp vNext 和 .NET Core 开发博客项目 - 统一规范API，包装返回模型
- [JavaWeb-HTML]HTML标签_文本标签_练习
- php中命名空间、面向对象、访问控制、接口
- linux shell 生产脚本汇总,【汇总】Linux常用脚本shell
- JAX 是 Google 开发的计算机视觉研究
- 由脚本创建的新元素事件不触发和用的easyUI插件中的多选框不起作用的解决方法...
- Web — 调色盘打开+div
- 【kuangbin专题】Manacher
- c语言窗口炸弹代码,C语言实现宾果消消乐
- C#winform【在状态栏显示实时时间】--实战练习一
- RingBuffer的快速上手使用方法
- 软件配置管理岗位职责说明
- c语言 ascii码转成字符串,ASCII码与字符串的相互转换
- 2001-2020年全国31省城镇居民人均可支配收入/居民实际收入水平
- 2018年全国大学生电子设计竞赛“TI杯”H题解析
- 《网络攻防》Web安全基础实践
- 视频知识点（23）- TS格式详解指南
- 《东周列国志》第三十回 秦晋大战龙门山 穆姬登台要大赦
- 使用代理服务器之后浏览器无法联网的解决办法