C++ 命名规范
代码规范一、 C++命名规范
开发中，模糊、混乱的命名往往导致代码的结构的臃肿、繁杂。因此良好的命名规则对开发来说无疑是事半功倍。何为“命名规范”，命名规范或者说命名规则指的是一致性的命名管理/命名风格。良好的命名规范甚至于我们不需要去了解其类型声明的条件就能理解其名字所代表的含义。
命名规范一般情况下是随着我们开发时长的增大，慢慢积累的，所以具有一定的自定义性。参考“Google 开源项目风格指南”以及自身的开发经验，笔者总结出自己的 C++命名规范。
（一）、通用的命名规则
概述
无论是函数还是变量命名，亦或是文件命名应该编写能够使人理解的名字。
解释
开发过程中，文件量、函数量往往是不可预见的、复杂的。所以在命名上应该依据文件具体功能、作用做出合理的具有描述性的名字，易于开发中理解。
/* 合理缩写 */
int size_of_salary; // 无缩写
int num_size; // “num”是常见缩写
int num_dns_connections; // “dns”也为大众熟知
int i; // 无意义
int nerr; // 模糊不清的词义
int n_size; // 模糊不清的缩写
int wpp_number_size; // 无法具体理解
int pc_size; // 使用常见缩写“pc”，但是具有多种解释
int flb; // 缩写严重
注意
应该少用缩写，特别是仅有项目开发者才能理解的缩写。若是使用一些常见缩写，例如：num、elemType 等也未必不可，需要自行斟酌，但切勿因节省空间大小而特意缩写。
对缩写也不能一棒子打死，广为人知的缩写是合理的。例如使用“i”表示迭代变量，使用“T”表示模板参数。
（二）、文件命名
概述
文件名应全为小写，可以包含下划线（_）和数字，但禁止以其开头。文件名应该具有一定描述性。
解释
开发中免不了出现各种文件，所以每种文件应该能够简略描述其功能、特性、特点等。同时应该禁止使用驼峰命名法，驼峰命名法虽然有助于提升命名阅读性，但是对于一个复杂的项目而言，大量的文件使用驼峰命名法会导致在文件管理器上阅读性下降。
在 C++中，文件后缀应该遵守：源文件以 .cpp 结尾，头文件以 .hpp 结尾。专门用于插入文本的文件则以 .inc 结尾。
通常为了使文件名更为清晰，应该对命名更为具体，例如：http_server.logs.hpp 就比 logs.hpp 更好，同时应该尽量保证类与实现方法文件名一致性，例如： share_stack.hpp 和 share_stack.cpp 其对应的类 ShareStack。
/* 合理文件名 */
exercise_one.cpp
test_stack.cpp
user.hpp
_size_of_employess.cpp // 不能使用_或数字开头
num_pcc.cpp // 无法理解的命名
user_num.cpp // 模糊不清，"user"具有多种解释
注意
不能使用已经存在于
/usr/include目录下的文件名，例如db.h
（三）、类型命名
概述
类型命名应该采用大驼峰命名法 ，且不能使用下划线。
解释
对于所有的类型命名，譬如：类、结构体、类型定义、枚举、类型模板参数等都应该使用此约定，即采用大驼峰命名法且不含下划线。
/* 类 */
class ExerciseOne{};
/* 结构体 */
struct Stack{};
/* 类型定义 */
typedef int ElemType;
/* using 别名 *
using PropertiesMap=hash_map<UrlTableProperties *, string>;
/* 枚举 */
enum ExerciseErroes{};
（四）、变量命名
概述
变量、函数参数和数据成员应该一律使用小写，同时使用下划线（_）将单词隔离。同时类的成员变量还需遵守以下划线结尾的规则。
解释
变量使用小写原因是为了保证代码的整洁性，将类成员变量命名结尾还需加入下划线是为了更好区分。
/* 普通变量命名 */
int user_name; // 好，符合规则
int username; // 中，未采用下划线分隔
int userName; // 差，大小写混用
/* 类数据成员 */
class Exercise{
public:
int user_name_; // 好，符合规则
int userName; // 差，大小写混用，且结尾未加_
static int user_name_; //好，无论静态还是非静态，都要接下划线
};
/* 结构体 */
/* 结构体变量符合一般要求即可，无需结尾加下划线 */
struct Stack{
int data;
int numbers;
static int value;
};
（五）、常量命名
概述
为区分常量和变量，声明为 constexpr 或 const 的变量，或在程序运行期间其值始终保持不变的，命名时以“k”开头，且使用 大驼峰命名法。
解释
具有静态存储类型的变量（例如：静态变量或全局变量），其与普通变量不同。用“k”作为开头能够提示阅读性和区分性。
const int kNumber=10;
（六）、函数命名
概述
普通函数应该采用小驼峰命名法，取值和设值函数应该与其变量名匹配。用于和类命名方式做区分。
解释
一般来说，使用大驼峰命名法命名函数能够与变量名做区分，感官上更加优雅。
同时对于缩写单词，应该视为一个单词且仅首字母大写，例如：startRPC() 应写成 startRpc()。
同时应将类中函数称为“方法”用于区分。
注意
同样的命名规范同时适用于类作用域与命名空间作用域的常量, 因为它们是作为 API 的一部分暴露对外的, 因此应当让它们看起来像是一个函数, 因为在这时, 它们实际上是一个对象而非函数的这一事实对外不过是一个无关紧要的实现细节。
取值和设值函数命名应该与对应变量名一致，例如：
int worker与void setWorker()、void getWorker()。
（七）、命名空间命名
概述
命名空间以小写字母命名，禁止使用缩写作为名称。其最高级命名空间名字取决于项目名称或者该命名空间中代码所属团队名字。
解释
命名空间名字应该是独特的，其命名空间中的代码，应当存放于命名空间的名字匹配的文件夹和其子文件夹中。同时需要避免嵌套的命名空间与常见顶级命名空间发生冲突所导致的编译失败。
注意
禁止创建嵌套的
std命名空间。
（八）、枚举命名
概述
枚举的命名应当和常量一致。
解释
enum Exercise{
kNumber=0,
kValue,
kErrorSize,
};
（九）、宏命名
概述
宏命名应该采用全为大写字母，且字母之间使用下划线（_）隔开。
解释
宏定义是特殊的，使用全大写字母让我们一眼就看出其特性。
#define MAX_SIZE 100
参考：
Google 开源项目风格指南
