组织和策略问题：1高警告级别干净利落的进行编译

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

1.    编译器是你的朋友，如果它对某个构造发出警告，这经常说明你的代码中存在潜在问题；

2.    排除警告的正确做法：

(1)  把它弄清楚；

(2)  改写代码以排除警告，并使代码阅读者和编译器都能更加清楚，代码是按照编写者意图执行的；

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

 

常见特定警告问题：

1.    第三方头文件：无法修改的库头文件可能包含引起警告(可能是良性的)的构造；

(1)  可以用自己的包含原头文件的版本将此文件包装起来，并有选择地为该作用域关闭烦人的警告，然后再整个项目的其他地方包含此包装文件；

(2)  Note:各种编译器的警告控制语句并不一样

 

2.    未使用的函数参数；

(1)  检查一下，确认确实不需要使用该函数参数(比如，这可能是一个为了未来扩展而设的占位符)，如果确实不需要，直接删除函数参数名就可以了；

3.    定义了从未使用过的变量；经常可以通过插入一个变来那个本身的求值表达式，使编译器不再报警；

Locklock;

lock;

4.    变量使用前可能未经初始化；…初始化变量；

5.    遗漏了return语句：

(1)  有时候编译器会要求每个分支都有一个return语句，即使控制流可能永远也不会到达函数的结尾(比如：无限循环，throw语句，其他的返回形式等)；

(2)  例如：没有default情况的switch语句不太适应变化，应该加上执行assert(false)的default情况；

6.    有符号/无符号数不匹配；

(1)  通常没有必要对符号不同的整数进行比较和赋值；因该改变所操作的变量的类型，从而使变量匹配；

(2)  最坏的情况下，要插入一个显示的强制转换；

 

例外情况：

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