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：能用常量替代宏的地方尽量使用常量吧；