分类： C/C++
2012-01-11 22:05:26
我平时工作大多用C语言，未用C++，本文主要对共用的部分的摘抄和总结。
我阅读了两个比较成熟的规范Google C++ Style Guide（ ）和白杨的主要参考Google，觉得白杨的编码规范写的太过死板和繁琐，不过变量的命名规范我很喜欢。推荐大家看英文原版，原版一直在更新。看规范时可以找一个代码来一起看一下，更有意思。
参考代码：
白 杨的变量命名构成为：作用域前缀+类型前缀+名称。这样可以很方便的知道一个变量的作用域和类型，不用跳转到定义出再去查看。但全部变量都这样定义我觉得 有些繁琐，在全局变量和struct成员中使用挺合适，因为单个函数总不是不大，单个函数内的局部变量可以很方便的知道其类型。
Google C++ Style Guide中让我眼前一亮的地方：
1、inline函数的使用。
2、C文件中头文件引用的顺序。
3、整形的使用，包含64位兼容性。
4、尽量少使用宏。
下面是摘抄内容：
1、防止头文件重复编译
foo/src/bar/baz.h => #ifndef FOO_BAR_BAZ_H_
宏名称包含 项目名称 + 路径（尽量完整） + 文件名
包含项目名称和路径可以尽量的减少重复
2、尽量减少头文件的引用
使用前置声明，如：class File; instead of having to #include "file/base/file.h"
3、inline函数
函数最好小于10行。
过度使用inline可能造成程序变慢。把小函数定义为inline可使代码段变小，把大函数定义为inline可能造成代码段变大，而在现在处理器上小的代码段执行更快，因为它更好的利用了cache。
函数内包含循环、switch语句，不能定义为inline。
定义在当前c文件中的inline函数是不能在其它c文件中使用的，如果使用则编译为一般函数调用。通常把inline函数定义放在头文件中，放在-inl.h头文件（加#define保护）。
4、函数参数
把input参数output参数前面
5、C文件中include头文件的顺序
顺序如下，第一个为当前C文件对应的头文件，不同类别之间用空行隔开。
1.dir2/foo2.h (preferred location — see details below).
2.C system files.
3.C++ system files.
4.Other libraries' .h files.
5.Your project's .h files.
6、函数变量
函数变量尽量置于最小的作用区域内（离第一次使用越近越好），并在变量声明的时候初始化。
7、静态和全局变量
不要在多线程程序中使用非const的静态变量。静态生存周期变量，包括全局变量、静态变量、静态类成员变量、函数静态变量，必须是原生的数据类型 （POD，P lain Old Data），只能是int，char，float，void以及POD构成的数组/结构体/指针。C++构造、析构对静态变量未明确定义。
8、const限定词
推荐在任何可能的情况下使用const。更容易理解，方便编辑器做检查。
如果函数不会修改传入的指针类型参数，则应该声明为const。
const int *x和int const *x含义相同，限制不能修改指针指向的值。
9、整形
在内建整形中，仅使用int，其它使用
不要使用uint32_t等无符号整形，除非你表示一个位组而不是一个数值。尤其不要为了指出数值不为负而使用无符号类型，相反，应该使用断言来保护数据。
使用断言来指出变量为非负数，而不是使用无符号类型！
for (unsigned int i = foo.Length()-1; i >= 0; --i) …；永远不会结束，而且gcc有时不会报错。
对于明显知道数值不会很大的，可以使用int。
10、64位下的可移植性
代码应对64位和32位系统友好，处理打印，比较，结构体对齐时切记。
11、预处理宏
使用宏时要非常谨慎，尽量用内敛函数，枚举和常量代替之。宏意味着你和编译器看到的代码是不同的，这可能回导致异常行为，尤其因为宏具有全局作用域。
不要在 .h 文件中定义宏.
在马上要使用时才进行 #define, 使用后要立即 #undef.
不要只是对已经存在的宏使用#undef，选择一个不会冲突的名称；
不要试图使用展开后会导致 C++ 构造不稳定的宏, 不然也至少要附上文档说明其行为.
12、0和NULL
整数用0，实数用0.0，指针用NULL，字符串用'\0'，当前gcc对NULL有特殊的定义，可以给出有用的警告信息，并且sizeof(NULL)和sizeof(0)并不一定相等的情况下。
13、sizeof
尽可能用sizeof(varname)代替sizeof(type)。使用sizeof(varname)，当代码中类型改变时会自动更新
14、一般变量命名
函数名称、变量名称、文件名称应具有描述性，避免缩写。类型和变量应该是名词，函数名应该是“命令性”的动词。
int num_errors; // Good.
int num_completed_connections; // Good.
int n; // Bad - meaningless.
int nerr; // Bad - ambiguous abbreviation.
int n_comp_conns; // Bad - ambiguous abbreviation.
不要使用缩写，除非它们在项目中是非常熟知的。
永远不要使用省略字母的缩写。
int error_count; // Good.
int error_cnt; // Bad.
15、文件命名
单词使用下划线'_'分割。
尽量使你的文件名特殊详细。For example, use http_server_logs.h rather than logs.h.
16、类型名称命名
类型包含：class，struct，typedef，enums
大写字母开始，每个单词第一个字母大写，并且无下划线。
// classes and structs
class UrlTable { ...
class UrlTableTester { ...
struct UrlTableProperties { ...
// typedefs
typedef hash_map
// enums
enum UrlTableErrors { ...
17、变量命名
小写字母，下划线分割。
class成员变量最后要以下划线结尾，struct成员和普通变量一样。
全局变量用g_开头，用来区分局部变量
18、常数变量
字母k开头，首字母大写。
const int kDaysInAWeek = 7;
19、枚举变量命名
两种命名方式，常量命名法和宏命名法，推荐使用常量命名法，可以避免和宏的冲突
enum UrlTableErrors {
kOK = 0,
kErrorOutOfMemory,
kErrorMalformedInput,
};
enum AlternateUrlTableErrors {
OK = 0,
OUT_OF_MEMORY = 1,
MALFORMED_INPUT = 2,
};
20、函数注释
函数注释：函数声明处注释描述函数功功能；定义处描述函数实现。
函数声明：对函数的功能和用法进行描述，但要避免啰嗦，显而易见的无需注释
函数的输入输出.
对类成员函数而言: 函数调用期间对象是否需要保持引用参数, 是否会释放这些参数.
如果函数分配了空间, 需要由调用者释放.
参数是否可以为 NULL.
是否存在函数使用上的性能隐患.
如果函数是可重入的, 其同步前提是什么?
函数定义：重点说明功能和实现要点，如果实现步骤，实现的理由，算法等等。
21、实现注释
向函数传入 NULL, 布尔值或整数时, 要注释说明含义, 或使用常量让代码望文知意.
永远不要用自然语言翻译代码作为注释。
对于 Chinese coders 来说, 用英文注释还是用中文注释, it is a problem, 但不管怎样, 注释是为了让别人看懂, 难道是为了炫耀编程语言之外的你的母语或外语水平吗；
22、格式
行长度不要超过80个字符。
使用空格，而不是tab。
返回值、函数名、参数名尽量放在同一行。如果过长，可以放下参数，甚至第一个参数。
如果可以增强可读性，简短的条件语句可以写在同一行。但包含else分支时不允许使用。
if (x == kFoo) return new Foo();
单行条件语句用不用大括号都可以。但如果有else语句，则必须都统一。
空循环使用{}或continue，而不是一个简单的分号。
while (condition) {
// Repeat test until it returns false.
}
for (int i = 0; i < kSomeNumber; ++i) {} // Good - empty body.
while (condition) continue; // Good - continue indicates no logic.
句点或箭头前后不要有空格，指针、地址操作符(*,&)之后不能有空格。
布尔表达式：逻辑与(&&)总位于行尾。
函数返回语句不要用圆括号包围。
return x; // not return(x);
水平留白：单行行尾不要留空格，当前现代化的编辑器都会自动删除行尾的空格，比如emacs。
垂直留白：越少越好，单屏显示的代码越多越容易理解控制流，代码越紧凑越好。
