《C++编程规范——101条规则、准则与最佳实践》笔记001

C++编程规范

C++ coding standards

Author
Herb Sutter 《Exceptional C++ Style》 《Exceptional C++》 《More Exceptional C++》
Andrei Alexandrescu 《Modern C++ Design》 Loki

组织和策略问题

如果人们按照程序员编程的方式修建房屋，那么一只啄木鸟就能毁灭整个文明。 ——Gerald Weinberg

第1条 在高警告级别干净利落地进行编译

摘要

高度重视警告：使用编译器的最高警告级别。
应该要求构建是干净利落的（没有警告）。
理解所有的警告。
通过修改代码而不是降低警告级别来排除警告。

讨论

如果编译器对某个构造发出警告，一般表明代码中存有潜在的问题。
成功的构建应该是无声无息的（没有警告的），否则会漏过真正的问题。

排除问题的正确做法是：（1）弄清楚；然后（2）改写代码以排除警告，并使代码阅读者和编译器都能更加清楚，代码是按编写者的意图执行的。

即使程序一开始似乎能够正确运行，也还是要这样做。即使你能够肯定警告是良性的，仍然要这样做。因为良性警告的后面可能隐藏着未来指向真正危险的警告。

示例

例1 第三方头文件

---

无法修改的库头文件可能包含引起警告（可能是良性的）的构造。如果这样，可以用自己的包含原头文件的版本将此文件包装起来，并有选择地为该作用域关闭烦人的警告，然后在整个项目的其他地方包含此包装文件。

//文件：myproj/my_lambda.h —— 包装了Boost的lambda.hpp
//应该总是包含此文件，不要直接使用lambda.hpp
//Boost.Lambda会产生一些已知无害的编译器警告
#pragma waring(push)  //仅禁用此头文件
    #pragma warning(disable:4512)
    #pragma warning(disable:4180)
    #include
#pragma warning(pop)

例2 未使用的函数参数

---

检查一下，确认确实不需要使用该函数参数（比如，这可能是一个为了未来扩展而设的占位符，或者是代码没有使用的标准化函数签名中的一个必须部分）。如果确实不需要，那直接删除函数参数名就行了。

//在一个用户定义的allocator中未使用hint
//警告：unused parameter localityHint
pointer allocate(size_type numObjects, const void * localityHint = 0)
{
    return static_cast(mallocShared(numObjects * sizeof(T)));
}
//消除了警告的新版本
pointer allocate(size_type numObjects, const void * /*localityHint*/ = 0)
{
    return static_cast(mallocShared(numObjects * sizeof(T)));
}

例3 定义了从未使用过的变量

---

检查一下，确认并不是真正要引用改变量。（RAII基于栈的对象经常会引起此警告的误报）。如果确实不需要，经常可以通过插入一个变量本身的求值表达式，使编译器不再报警。（这种求值不会影响运行时的速度）

//警告：variable 'lock' is defined but never used
void Func()
{
    Lock lock;
    //...
}
//可能消除了警告的新版本
void Func()
{
    Lock lock;
    lock;
    //...
}

例4 变量使用前可能未经初始化

---

初始化变量

例5 遗漏了return语句

---

有时候编译器会要求每个分支都有return语句，即使控制流可能永远也不会到达函数的结尾（比如：无限循环，throw语句，其他的返回形式等）。这可能是一件好事，因为有时候你仅仅是认为控制不会运行到结尾。例如，没有default情况的switch语句不太适应变化，应该加上执行assert(false)的default情况。

//警告：missing "return"
int Fun(Color c)
{
    switch(c)
    {
    case Red:   return 2;
    case Green: return 0;
    case Blue:
    case Black: return 1;
    }
}
//消除了警告的新版本
int Fun(Color c)
{
    switch(c)
    {
    case Red:   return 2;
    case Green: return 0;
    case Blue:
    case Black: return 1;
    default:    assert(!"should never get here!"); //!"string"为false
                return -1;
    }
}

例6 有符号数/无符号数不匹配

---

通常没有必要对符号不同的整数进行比较。应该改变所操作的变量的类型，从而使类型匹配。最坏的情况下，要插入一个显式的强制转换。

不管怎么样，编译器都将为你插入一个强制转换，同时还会发出警告，因此还不如显式地先发而制之。

例外情况

有时候，编译器可能会发出烦人的甚至虚假的警告（即纯属噪声的警告），但是又没有提供消除的方法，这时忙于修改代码解决这个警告可能是劳而无功或者事倍功半的。如果遇到了这种罕见的情形，作为团队决定，应该避免对纯粹无益的警告再做无用功：单独禁用这个警告，但是要尽可能在局部禁用，并且编写一个清晰的注释，说明为什么禁用。