[逼死强迫症 - C&C++设计风格选择.1] : 命名规范

1.命名规范

　　本系列的第一篇，命名风格本就是有关艺术审美，没有美与丑的绝对标准，本文难免带有主观选择倾向，但是会尽量保持客观的态度归纳几种主流的命名风格，仅供参考。制定规范是为了方便团队沟通和利于代码维护，虽然并不能符合每个艺术家的胃口。对于独立开发者，花点时间设计自己的编码风格也是有助于提高能力的，至少可以在看到自己代码的时候感觉美美哒~~。本文参考了<Google C++ 风格指南>，<Qt 编码风格>，当然还有维基百科，以后不累述。

1.1.常见命名法

蛇形命名法　[snake_case]：

　　like_this，常见于Linux内核，C++标准库，Boost以及Ruby，Rust等语言。

驼峰命名法　[camelCase]：

　　likeThis，为了和帕斯卡命名法区分，本文特指小驼峰式命名法，常见于Qt以及Java。

帕斯卡命名法[PascalCase]：

　　LikeThis，又名大驼峰式命名法，常见于Windows API函数以及C#。

匈牙利命名法[Hungarian notation]：

　　dwWidth，系统匈牙利命名法是被黑的最多的，主要认为在有类型检查的语言里发现类型错误编译器比人更可靠；在有IDE的情况下，找到一个变量的类型也不是一件难事；通常我们看到一个陌生的变量的时候，如果不知道它是干什么的，知道它的类型好像也并没有什么用；并且在重构的时候，如果你要改变一个变量的类型，尽管其功能并没有变，你还是要去修改变量名。所以除非是Windows系统开发，不建议使用系统匈牙利命名法。

　　rwPosition，匈牙利应用命名法不表示变量的类型，而是用前缀表示变量的目的，或者它代表了什么。这种变量命名方法在帮助程序员理解变量的用途上是很有帮助的。但是建议前缀不要使用缩写，除非所用的缩写是普遍共识。

1.2.文件命名

文件名后缀：

 # C语言不纠结
 file.h & file.c
 # C++ Group.(注意C是大写)
 file.h & file.C
 # C++ Group.
 file.hh & file.cc
 # C++ Group.
 file.hpp & file.cpp
 # C++ Group.
 file.hxx & file.cxx

tip.1：c语言没有选择，以下仅讨论c++；

tip.2：各组合可以混搭，比如常见的file.cpp搭配file.h和Google风格的file.cc搭配file.h；

tip.3：强迫症可以选择不混搭的各组，这样看起来有对称感；

tip.4：不要选择第1组大写C的后缀，特别是在Windows这样不区分大小写的操作系统上；

tip.5：一些后缀名可能不被某些较老的编译器或IDE所默认支持，例如vs2005默认没有扩展.hh后缀；

tip.6：如果需要跨平台，推荐选择第3组，至少boost是这么选的；

 

文件名命名：

 # Teddy项目UserLog文件为例：
 # Group.
 UserLog.c & TedUserLog.c
 # Group.
 userlog.c & teduserlog.c
 # Group.
 userlog.c & ted_userlog.c
 # Group.
 user_log.c & ted_user_log.c
 # Group.
 user-log.c & ted-user-log.c

tip.1：如果需要将源码直接发布，可以使用项目名做前缀，防止链接时文件名冲突(msvc好像能自动重命名冲突的.obj文件，但是跨平台程序不能依赖这个特性)；

tip.2：各组文件名风格都没有明显的缺点，但要注意在区分大小写的系统上UserLog.c和userlog.c是两个文件；

1.3.类型命名

 /*
 ** 基本数据类型的重定义，小写比首字母大写更有利于延长Shift寿命，
 ** 但也更容易产生命名冲突。
 */
 typedef unsigned char byte;
 typedef unsigned char byte_t;
 typedef unsigned char Byte;
 typedef unsigned char Byte_t;

 /*
 ** 类与结构体常见的风格是采用PascalCase，不推荐使用camelCase
 ** 这种怪异的风格。
 */
 class HashTable { ...
 class hash_table { ...
 struct FileInfo { ...
 struct file_info { ...

 /* C语言常见到的风格还有结构体名称加'_t'后缀 */
 struct fileinfo_t { ...
 struct FileInfo_t { ...

 /* 枚举命名常见PascalCase风格 */
 enum FileFlags { ...
 enum file_flags { ...

tip.1：c语言没有命名空间，为防止命名冲突，常见做法是将项目名或其缩写作为类型名称前缀；

tip.2：类，结构体，枚举的命名风格尽量保持一致；

1.4.命名空间命名

 /* 一般使用项目名称，风格看喜好。 */
 namespace my_project { ...
 namespace MyProject { ...

tip.1：确保命名空间不会和常用的库冲突；

1.5.函数和变量命名

 /*
 ** 在函数和变量命名风格上PascalCase，camelCase，
 ** snake_case三足鼎立，选择凭喜好。
 */
 void FunctionName(void) { ...
 void functionName(void) { ...
 void function_name(void) { ...

 long VarName;
 long varName;
 long var_name;

 /*
 ** tip.1：snake_case在名称比较长时可读性较好；
 */
 long variable_names_in_snake_case;
 long VariableNamesInPascalCase;
 long variableNamesInCamelCase;

 /*
 ** tip.2：PascalCase和camelCase在函数中的区分度较好，
 ** 在快速扫描代码逻辑的时候不易被其它符号所干扰。
 */
 long FabonacciFunction(long rabbitNums)
 {
     if (rabbitNums < ) {
         return rabbitNums;
     }
     long resultOne = FabonacciFunction(rabbitNums - );
     long resultTwo = FabonacciFunction(rabbitNums - );
     return resultOne + resultTwo;
 }

 long fabonacci_function(long rabbit_nums)
 {
     if (rabbit_nums < ) {
         return rabbit_nums;
     }
     long result_one = fabonacci_function(rabbit_nums - );
     long result_two = fabonacci_function(rabbit_nums - );
     return result_one + result_two;
 }

tip.3：如果类需要兼容标准库迭代器或是要支持range for，begin()和end()函数会破坏PascalCase风格的一致性；

1.6.类成员变量和全局变量命名

 /*
 ** 类成员变量和全局变量的命名风格和局部变量的命名风格
 ** 并没有更多的区别。唯一的问题是，是否要加前缀或后缀
 ** 以方便和局部变量区分开来。
 */
 class UserInfo {
     ...
 private:
     std::string user_name_; /* Google style */
     std::string m_userName; /* Hungarian notation */
     /* 不推荐前缀'_'的风格，可能会和标准库命名冲突 */
 };

 /* 全局变量要少用，推荐加前缀用于区分 */
 extern "C" long g_commonCount;

tip.1：在有IDE提示时，前缀"m_"的类成员变量能够很快被找到，如果不喜欢这种风格，"this->"同样也很便利；

1.7.常量和枚举值命名

 /*
 ** 常量和枚举值的命名风格建议和局部变量的命名风格区分开，
 ** 常见的有全字母大写加'_'的风格，PascalCase风格，以及
 ** Google加'k'前缀的风格。
 */
 static const int DAYS_IN_WEEK = ;
 static const int kDaysInWeek  = ;

 enum FileOpenMode {
     ReadOnly, WriteOnly, ReadWrite
 };

 enum FileOpenMode {
     READ_ONLY, WRITE_ONLY, READ_WRITE
 };

tip.1：如果可以使用c++11特性，推荐enum class，否则可以在有歧义的枚举值中重复枚举类型的名字；

1.8.宏命名

 /* 宏命名推荐使用全字母大写加'_'分隔的风格 */
 #define OS_UNIX
 #define OS_LINUX
 #define OS_WINNT

 /* 除非你想用条件编译将某些功能变为可选项 */
 #ifdef  USE_TCMALLOC
 #define my_malloc tcmalloc
 #else
 #define my_malloc malloc
 #endif

tip.1：能用常量替代宏的地方尽量使用常量吧；