原则:
高度重视警告:使用编译器的最高警告级别。应该要求构建是干净利落的(没有警告)。理解所有的警告。通过修改代码而不是降低警告级别来排除警告。
解释:
编译器是你的朋友。如果它对某个构造发出警告,一般表明代码中存有潜在的问题。
成功的构建应该是无声无息的(没有警告的)。如果不是这样,你很快就会养成不仔细查看输出的习惯,从而漏过真正的问题。
排除警告的正确做法是:(1)把它弄清楚;(2)改写代码以排除警告,并使代码阅读者和编译器都能更加清楚,代码是按编写者的意图执行的。
即使程序一开始似乎能够正确运行,也还是要这样做。即使你能够肯定警告是良性的,仍然要这样做。因为良性警告的后面可能隐藏着未来指向真正危险的警告。
示例:
1. 第三方头文件。
无法修改库头文件可能包含引起警告(可能是良性的)的构造。如果这样,可以用自己的包含头文件的版本将次文件包装起来,并有选择的为该作用域关闭烦人的警告,然后在真个项目的其他地方包含此包装文件。
2. 未使用函数参数。
检查一下,确认确实不需要使用该函数参数(比如,这可能是一个为了未来扩展而设的占位符,或者是代码没有使用的标准化函数签名中的一个必需部分)。如果确实不需要,那直接删除函数参数名就行了。
//。。。。在一个用户定义的allocator中未使用hint。。。。。
//警告:unused parameter 'localityHint'
pointer allocate(size_type numObjects,const void *localityHint = 0)
{
return static_case<pointer>(mallocShared(numObjects *sizeof(T)));
}
//消除了警告的新版本
pointer allocate(size_type numObjects,const void * /*localityHint*/ = 0)
{
return static_case<pointer>(mallocShared(numObjects *sizeof(T)));
}
3. 定义了从未使用的变量
检查一下,确认并不是真正要引用该变量。如果确实不需要,经常可以通过插入一个本身的求职表达式,使编译器不再报警。
//警告:variable 'lock' is defined but never used
void Fun()
{
Lock lock;
//......
}
//可能消除了警告的新版本
void Fun()
{
Lock lock;
lock;//这一句是关键
//......
}
4. 变量使用前可能未经初始化
需要初始化变量
5. 遗漏了return语句
有时候编译器会要求每个分支都有return语句,即使控制流可能永远也不会到达函数的结尾。这可能是一件好事,因为有时候你仅仅是认为控制不会运行到结尾。例如,没有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. 有符号/无符号数不匹配
通常没有必要对符号不同的整数进行比较和赋值。应该改变所操作的变量的类型,从而使类型匹配。最坏的情况下,要插入一个显示的强制转换。
7.有时候编译器可能会发出烦人的甚至虚假的警告(即纯属噪声的警告),但是又没有提供消除的方法,这时忙于修改代码解决这个警告可能是劳而无功或者事倍功半的。如果遇到了这种罕见的情形,作为团队决定,应该避免对纯粹无益的警告再做无用功:单独禁用这个警告,但是要尽可能在局部禁用,并且编写一个清晰的注释,说明为什么必须禁用。