C++代码规范,督促自己写规范的代码。
主要参考Google 的C++ 风格指南，总结一下，便于规范自己的代码。
1. 总体规则
总体上函数命名，变量命名， 文件命名 要有描述性， 少用缩写. 尽可能使用描述性的命名，让代码易于理解更重要.不要用只 有项目开发者自己能理解的缩写，也不要通过砍掉几个字母来缩写单词。并且使用合适的缩进，添加必要的空格,让代码看起来美观。
2. 文件命名
文件名要全部小写，可以包含下划线 ( _ ) 或连字符 (-)，我跟喜欢下划线“_” 。
eg:
robot_control_system.cpp
3. 类型命名
类型名称的每个单词首字母均大写，不包含下划线。
eg:
class RobotControl
{ ...
};
说明:
所有类型命名，类， 结构体， 类型定义 (typedef)，枚举，类型模板参数 均使用相同约定，即以大写字母开始，每个单词首字母均大写，不包含下划线。
eg:
//类和结构体
class RobotPosition
{ ...
};
struct RobotPosition
{ ...
};
4. 变量命名
变量 (包括函数参数)和数据成员名一律小写，单词之间用下划线连接，类的成员变量以下划线结尾，但结构体的就不用。
eg:
robot_speed , struct_data_member, a_class_data_member_.
//普通变量命名
string student_name; // 用下划线.
//类数据成员，不管是静态的还是非静态的，类数据成员都可以和普通变量一样，但要接下划线.
class RobotPosition
{
public:
...
private:
float position_x_;
float position_y_;
};
//结构体变量，不管是静态的还是非静态的，结构体数据成员都可以和普通变量一样，不用像类那样接下划线。
struct RobotPosition
{
float position_x_;
float position_y_;
};
5. 常量命名
声明为 constexpr 或 const 的变量，或在程序运行期间其值始终保持不变的，命名时以 “k” 开头， 大小写混合。
例如: const int kRobotSpeed = 70;
所有具有静态存储类型的变量 (例如静态变量或全局变量, 参见 存储类型) 都应当以此方式命名。对于其他存储类型的变量。如自动变量等，这条规则是可选的。如果不采用这条规则，就按照一般的变量命名规则。
6. 函数命名
常规函数使用大小写混合或者全使用小写字母用下划线分隔， 取值和设值函数则要求与变量名匹配。
void RobotMove()
{
...
}
//在UNIX/LIUNX这样的环境，以及GNU代码中使用非常普遍。
void set_robot_position()
{
...
}
一般来说, 函数名的每个单词首字母大写 (即 “驼峰变量名” 或 “帕斯卡变量名”)， 没有下划线。对于首字母缩写的单词, 更倾向于将它们视作一个单词进行首字母大写 (例如, 写作 StartRpc() 而非 StartRPC()).取值和设值函数的命名与变量一致。一般来说它们的名称与实际的成员变量对应, 但并不强制要求。 例如 int count() 与 void set_count(int count)
7. 枚举命名
枚举的命名应当和常量或宏一致: kEnumName 或是 ENUM_NAME。
单独的枚举值 应该优先采用常量的命名方式。 但宏方式的命名也可以接受. 枚举名 RobotMode是类型，所以要用大小写混合的方式。
enum RobotMode
{
kStop = 0,
kFastMove,
kErrorState,
};
谷歌的建议
2009 年 1 月之前, 我们一直建议采用宏的方式命名枚举值. 由于枚举值和宏之间的命名冲突，直接导致了很多问题。 由此，这里改为优先选择常量风格的命名方式。 新代码应该尽可能优先使用常量风格。 但是老代码没必要切换到常量风格, 除非宏风格确实会产生编译期问题。
8. 宏命名
宏全部大写，单词之间用下滑线隔开
#define ROUND(x) …
#define PI_ROUNDED 3.0
9. 命名空间命名
命名空间以小写字母命名。 最高级命名空间的名字取决于项目名称.。要注意避免嵌套命名空间的名字之间和常见的顶级命名空间的名字之间发生冲突。
顶级命名空间的名称应当是项目名或者是该命名空间中的代码所属的团队的名字。命名空间中的代码，应当存放于和命名空间的名字匹配的文件夹或其子文件夹中。
注意 不使用缩写作为名称 的规则同样适用于命名空间. 命名空间中的代码极少需要涉及命名空间的名称，因此没有必要在命名空间中使用缩写。
要避免嵌套的命名空间与常见的顶级命名空间发生名称冲突。由于名称查找规则的存在， 命名空间之间的冲突完全有可能导致编译失败。 尤其是， 不要创建嵌套的 std 命名空间。建议使用更独特的项目标识符 (websearch::index, websearch::index_util) 而非常见的极易发生冲突的名称 (比如 websearch::util)。
对于 internal命名空间，要当心加入到同一 internal 命名空间的代码之间发生冲突 (由于内部维护人员通常来自同一团队，因此常有可能导致冲突). 在这种情况下，请使用文件名以使得内部名称独一无二 (例如对于 frobber.h，使用 websearch::index::frobber_internal)。
