《C++编程规范——101条规则、准则与最佳实践》笔记001
2016-08-30 21:43
369 查看
C++编程规范
C++ coding standardsAuthor
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<boost/lambda/lambda.hpp> #pragma warning(pop)
例2 未使用的函数参数
检查一下,确认确实不需要使用该函数参数(比如,这可能是一个为了未来扩展而设的占位符,或者是代码没有使用的标准化函数签名中的一个必须部分)。如果确实不需要,那直接删除函数参数名就行了。
//在一个用户定义的allocator中未使用hint //警告:unused parameter localityHint pointer allocate(size_type numObjects, const void * localityHint = 0) { return static_cast<pointer>(mallocShared(numObjects * sizeof(T))); } //消除了警告的新版本 pointer allocate(size_type numObjects, const void * /*localityHint*/ = 0) { return static_cast<pointer>(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 有符号数/无符号数不匹配
通常没有必要对符号不同的整数进行比较。应该改变所操作的变量的类型,从而使类型匹配。最坏的情况下,要插入一个显式的强制转换。
不管怎么样,编译器都将为你插入一个强制转换,同时还会发出警告,因此还不如显式地先发而制之。
例外情况
有时候,编译器可能会发出烦人的甚至虚假的警告(即纯属噪声的警告),但是又没有提供消除的方法,这时忙于修改代码解决这个警告可能是劳而无功或者事倍功半的。如果遇到了这种罕见的情形,作为团队决定,应该避免对纯粹无益的警告再做无用功:单独禁用这个警告,但是要尽可能在局部禁用,并且编写一个清晰的注释,说明为什么禁用。相关文章推荐
- 《C++编程规范——101条规则、准则与最佳实践》笔记004
- 《C++编程规范——101条规则、准则与最佳实践》笔记002
- 《C++编程规范——101条规则、准则与最佳实践》笔记000
- 《C++编程规范——101条规则、准则与最佳实践》笔记007
- 《C++编程规范——101条规则、准则与最佳实践》笔记008
- 《C++编程规范——101条规则、准则与最佳实践》笔记003
- 《C++编程规范——101条规则、准则与最佳实践》笔记009
- 《C++编程规范:101条规则、准则与最佳实践》
- C++编程规范--101条规则、准则与最佳实践
- 强烈推荐C++编程规范:101条规则、准则与最佳实践
- 强烈推荐C++编程规范:101条规则、准则与最佳实践
- 读书笔记之:C++编程规范——101条规则、准则和最佳实践
- 《C++编程规范-101条规则 准则与最佳实践》读书笔记
- 《C++编程规范:101条规则、准则与最佳实践》学习笔记
- C++编程规范(101条规则、准则与最佳实践)
- 《C++编程规范 101条规则、准则与最佳实践》 人邮 -- 读书笔记
- C++编程规范:101条规则、准则与最佳实践pdf
- Scala中隐式转换内幕操作规则揭秘、最佳实践及其在Spark中的应用源码解析之Scala学习笔记-55
- C++ Coding Standards:101条准则、指导方针和最佳实践
- ant的最佳实践笔记