C++代码规范（精简版）

最新推荐文章于 2024-04-12 15:02:32 发布

Crawl.W

最新推荐文章于 2024-04-12 15:02:32 发布

阅读量1.1k

点赞数 3

分类专栏： C++ 文章标签： C++ 代码规范编程基础

本文链接：https://blog.csdn.net/qq_27564553/article/details/96340744

版权

C++ 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

博客写于自己读《代码简洁之道》前，所以这些代码的规范基本源于身边前辈的传授、自己的体悟和别人的博客。读了《代码简洁之道》，对原来命名的一些困惑有豁然开朗之感，书中大部分的建议窃以为是目前最优的命名规范，建议大家移步该书。后期会考虑把书中好的又不为人所知的观点或者不太好理解的建议在此博客更新。

顺势推荐一个对《代码简洁之道》总结的博客——代码整洁之道(一)。文末有重点，一定要看。

编制目的

本规范的编制，目的在于增加程序的可读性，可维护性，减少合并代码、修改代码、审批代码等操作可能产生的错误。
在具体的软件开发中，编制规范主要包括并不限于以下作用：

程序员可以清楚了解某段代码在做什么，即使很久没有接触。
新进人员可以很快接手原有代码。
初学者可以少犯前人已经犯过的错误。
规定的命名以减少部分命名问题带来的苦恼。

编制原则

本规范的编制，主要基于以下的原则进行编制，开发人员在开发过程中应遵循以下原则并作为代码开发设计的指导：

精简性

只加入重要的，有充足理由的规范，取简短且无歧义的名字。单词过长首先使用通用缩写，没有通用缩写自定义缩写且注释。

精确性

清晰地描述与什么有关，去除无关表述。

分解性

无论怎么简化仍然是很长的名字串到一起，考虑是否杂糅太多期望，分解期望。

整体性

保证代码整体风格的一致，避免繁琐和臃肿。

命名规范

首先要求是要能确切地体现用途，包括变量、函数、类的命名。
其次，省略与用途无关的字符，舍弃部分代码规范的成见，如匈牙利命名法。其要求变量中附带类型前缀及作用域标志等，在现代编辑器中无太大意义且冗长。
目前没有一种命名规范可以让所有的程序员赞同，本命名规范只做简单的规范讨论，符合以上原则即可，大家依此执行规范。

变量

变量命名中无需含有表示变量或参数类型的单词或表述，现代编辑器可以很容易地定位到变量的类型，且很多现代编程语言采用非静态类型。
对代码的理解影响不大的变量，如循环变量（int i, j , k）,可以不遵守以上规范
指针变量建议加p,指针的指针加pp。
成员变量加“_”后缀

优秀示例

要求规范	错误举例	改进
map<name, value>valuebykey	Map<Employee, Role> employRoleHashMap	employeeRoles
List<> -s, -es	List<DateTime> holidayDateList	holidays

常量

全局常量命名全部使用大小字母，单词之前用_分隔，可以用define, enum和const来定义常量，如：

结构体命名

结构体首字母大写，成员变量采用小写开头，如：
在这里插入图片描述

函数

函数名应使用动词和动词短语命名，如checkError(),而不是errorCheck()。且首字母小写（此处定义也是为了符合qt代码规范，及qml中js函数定义要求）。
函数的定义：要包含完整的参数类型，参数名称，而不是仅包含参数类型。
返回值：没有返回值时，用void作为返回值。
形参与返回值类型：若参数或返回值的类型是指针或引用（reference）,且指针指向的内容或引用的内容不应该被函数体改变（对于参数）或不应被函数调用者改变（对于返回值），参数和返回值应用const限定。
模块接口函数：需要与别人合作的模块接口函数应包含功能描述，参数说明，返回值说明。如：

在这里插入图片描述

类名：类名表示抽象对象或对象，使用名词或名词短语，首字母大写，一定要摒弃匈牙利命名规范开头加C表示类的用法，这样的添加属于无意义的字符添加且与现代C++中结构体也是类的表达方式区别略大。
模块类：需要与别人合作的模块类，应该包含功能描述。
类的格式：
将类的public interface 放到类定义的最前面，其后是protected,最后才是private。对于类的public接口又分四种类型：
- LIFECYCLE: constructor/destructor属于该类型
- ACCESS: 属性访问函数属于该类型
- INQUIRY: 查询函数（以Is开头的函数）属于该函数
- OPERATIONS: 除上面以外的所有interface归于此类

作此规范源于：类是供使用的，对类的用户来说，最重要的是如何使用该类，所以应该将类的公共接口放在类定义的最前面。而对类进行public interface的分类/分组可以帮助类的使用者快速了解和定位这些interface。
析构函数：如果该类会（或可能）作为基类被继承，请将该类的destructor定义为virtual，这样在通过基类指针删除派生类对象时正确的destructor才会被调用。

缩略词
缩略词如果放在开头用，采用变量，函数等其他规则适配，尽量使用通用的缩写，如果自定义缩写，在文件开头做注释。
单位信息
在需要的地方（比如各种单位转换的情况），包含单位信息。如：
类或库函数的命名冲突
使用name space，不建议使用前缀。有些情况下可以使用前缀，如MFC中大部分全局函数都是以Afx为前缀的，全局的常量也是有一些前缀，对于企业内部软件开发来说，必定是稳定通用的库函数或变量才可以通过加前缀的方式避免命名冲突。

省略规范

去除命名中不是用来消除歧义的表述。
去除命名中可以上下文获取的表述。
去除命名中没有任何含义的表述。

代码守则

变量初始化
初始化所有变量，很多问题都是变量未初始化导致的，请初始化所有变量。即使你现在清楚它们在后面会100%被赋值，你同样需要这么做，否则新人接手你的代码时，可能会在理解和维护你的代码上遇到困难。
全局变量引用
慎用全局引用或者被其他共享数据引用的变量，如引用gobal或static变量，因为在多线程中会产生副作用。
标识常量及魔鬼数字
尽量使用标识常量，而不是直接使用数字或字符串（魔鬼数字），这将有助于减少书写错误，是代码更容易理解和修改。

建议

恒等格式：将常量置于“==”左边，有助于减少将“==”写成“=”的错误。
布局合理
代码行长度不宜过长，需要水平滚动窗口不便于阅读或打印，建议代码长度在11号字体，左右侧有且只有一个工具栏的情况下，在屏幕中的占比不超过整个屏幕的3/5。
头文件中避免多重包含，使用以下格式宏定义来避免多重包含，而不是使用特定编译器的命令，如应该避免使用#program once而采用如下的宏：

#ifndef SAMPLEMODEL_H
#define SAMPLEMODEL_H
//some code
#endif //SAMPLEMODEL_H

使用助记符：在注释中添加助记符，由于突出一些潜在问题，方便后期的查找定位。
TODO：指出有进一步的工作待完善，待优化

BUG：指出有bug,需要描述bug状态，知道产生条件补充条件
TRICKY：指出代码较复杂，有一定的技巧，没有完全理解前不要修改
WARNING：指出有些东西需要特别注意
NOTE: 指出一些需要解释的内容
注释：注释大段代码，使用#if 0, #endif，如：
释放资源：安全释放资源，在释放内存或其他资源时，尤其分配和释放不在同一函数中时，请使用以下较安全的写法（前提是所有变量有初始化）：
Release Note
每个项目和模块都必须包含一个Release Note文件，其内容为相应版本所做的修改，如：