世有C++, 尔后有Effective C++, 再后有More Effective C++, 然后是pc-lint对违反这些经典条款的自动侦测.
光是建议一种做法, 听者仅是赞同认可, 而没有给出可行的方案让大家简易便捷地就能遵从, 仅靠程序员的个人自觉, 根据我的观察, 这在实践中往往是不会生效的, 表现就是不管你开过多少次会, 发过多少次code review的反馈mail, 推荐过多少次书籍, 每个人固有的习惯依然在继续, 每次一个问题被指出来, 就修改一次, 有错就改, 改完再犯.
我还是宽容一点, 毕竟我自己也同样是积习难改, 问题的一端是: 请自己遵从好的做法, 另一端则是: 我如何知道我没有遵从, 或者变换一下: 我如何知道项目的代码里何处没有遵从.
对 [More] Effective C++系列中闪光的建议就是这样需要被自动检查的东西, 而pc-lint就是可以执行这样检查的东西:
这是一个例子, 以上是pc-lint的文档, 每一条错误/警告信息中都给出了解释乃至出处. 第12号参数是指Scott Meyer的 Effective C++, 而第23号则指More Effective C++, 后面的Item 12当然指书中的第12号条款.
其中Effective C++现今已出到了第三版. 但我拿到手的这份pc-lint文档是8.00x中的, 其引用的书籍是第一版的, 手头上有侯捷译的第二版 Effective C++, 其中作者说个别条款的顺序和内容有些调整. 幸好只是个别的, 4个以内.
我计划的做法是: 从pc-lint文档中抽出 [More] Effective C++ 条款相关的警告, 把它加入我们已经在执行的pc-lint对代码的检查中, 一旦有违反, 至少可以在提交代码后的1-2天内给出反馈, 此时修改, 似乎还来得及. 这种修改对代码作者是一种警醒: 最好以后自己注意一次作对, 而不是等着一个自动工具对你的代码指手划脚.
额外的工作是: 我不能简单是抽取一个数字代表的错误/警告代号即可, 事情远没那么简单, pc-lint给出的错误/警告有一定的信噪比, 基本上我得对50+35个条款逐个试验, 看有没有误报.
也正是因为这个原因, 我目前对pc-lint的使用策略是, 先用-e* 去掉所有的警告, 然后, 随着我自己对pc-lint每个警告的个别认识, 逐个/逐批添加上去. 比如违反了printf的使用格式符是个严重的问题, 也没发现pc-lint有误报, 我就得把printf/scanf相关的错误号全部加上, 这不是一个, 而是一组相关的警告代码.
class T {
public :
T(int ) { }
};
class X {
string s;
T t;
public:
X() // :t(1), s("asdf")
{
// s = "asdf";
}
~X() { puts("dtor") ; }
static const int NUM = 3;
};
|
对以上代码, 如果我注释掉initialization list, 就会出现 1926号警告, 而去掉注释后, 因为有意把t和s的顺序颠倒了, 还会出现 1729 号警告.
并非所有在书里的Item pc-lint都有相应对策, 可能是一些实现上的困难, 我的搜索是, 仅有以下Item能被自动检查.
而More Effective C++相关的:
另一个问题, 每个Item 都可能有一些要违反的例外, 还得有故意违反例外时如何显式通知pc-lint网开一面的机制, 这一般通过
//lint -save -eXXXX
code
//lint -restore
实现.
阅读(963) | 评论(0) | 转发(0) |
