Coverity 静态分析 VS Code Review 代码审查

转自：http://blog.youkuaiyun.com/wushangwuhen123/article/details/51475278

中文翻译首发，转载需全文（或跟逸松打个招呼:)）。 

最近最经常被问到的一个问题：Coverity代码静态分析找到的Bug中，有多少是能够在Code Review（代码审查）过程被发现的？

其实我们并没有统计过详细的数据-事实上你很难回答一个百分比，因为太牵强。我们用另一个方式来聊一聊下这个问题。

目前Coverity团队在持续不断的分析上亿行开源代码库（包括C、C++、Java、C#代码），分析结果生成了一个庞大的数据库。每星期所有的研发人员都会确认找到的Bug是否为误报或者漏报-要知道这些代码不是由他们编写，完全读懂的难度也很大。（“漏报”和“误报”是静态分析行业的 术语。漏报代表某个Bug没有被找到。误报指的是找到的问题不是Bug）。

在整个过程中，我们通常会浏览代码上下文，确认是否有某些缺陷没有被发现。没被发现的缺陷被标记为“漏报”，不是Bug的问题将被标记为“误报”，接下来研发团队将调整Coverity的分析引擎以保证最精确的结果。

这项工作持续了多年，每周都会进行，我们积累了非常多的经验：哪些Bug可以很轻松的被Code Review发现-很多Bug简单直接，只要你料及并注意的话。除此之外，很大一部分Bug无法被Code Review流程发现-要么潜藏在深层次的架构中，要么跨越了多个文件和分支，需要深度理解复杂的上下文，通过查看大量代码以确定多个方法的语义。

举个例子好了：

try { 

  Foo(); 

} 

catch(Exception ex) { 

  new WrapperException(ex); 

}

这几行代码中的问题显而易见，但是如果代码超过了一百行，而且我没告诉你这一段程序中包含一个Bug，你还会发现这个问题吗？

你可能会说一个好的Code Review流程一定能够发现此类问题。但是我们在海量代码分析的过程中发现了太多此类问题-事实上这些问题很难被Code Review流程发现，因为代码审查人员往往并不能够很细致的查看代码并发现这些Bug。

更有意思的是，我们发现报告这个缺陷的Java代码库数量大于C#代码库-还没确定具体的原因（逸松：可能是Java开源代码比C#要多，偷笑ing,大家如果有自己的意见可以直接添加留言）。

这是唯一一个Eric自己写的Checker（静态分析规则），很简单直接，完全是intraprocedural的分析，不需要去理解函数间的控制流。之前提到过，在审查某个Bug的时候我们往往会同时看看邻近的代码上下文中是否有其他问题，要知道程序员往往不会只犯一个错误，而且错误之间往往是相互联系的。

这个Checker的起源，来自于一个客户代码的审查过程中，方法包含的缺陷：

if (parameter == null ) 

  new ArgumentNullException("parameter");

这个方式的代码看起来没啥太大问题，最差的结果是出现一个空指针引用异常，而不是空对象调用异常。但是前一个例子中的 “try-catch”语句中的Bug是不可原谅的，我们已经看到了非常多的实际代码异常：“出于安全因素，你需要避免这个方法的使用”，当然, try-catch语句避免了这个异常，削弱了代码的安全性。

话说远了，我们继续聊Code Review。

经常遇到的一个状况是：在与研发团队确认Coverity找到的代码缺陷过程中，研发人员否认代码中的真实Bug。同样也举个栗子，我们经常遇到信心满满的程序员告诉我们：我的C程序调用了一个内存已经被释放的指针，但这块内存已经确认不会被下一条语句修改，所以最终用户在使用过程中不会有任何问题。所以他们一直相信奇迹--内存跟牛奶不一样，是不会毁坏的。某些程序员直接拒绝修复这一类缺陷因为使用已释放的代码“是没有问题的！”。因此假如在Code Review的过程中，假如程序员本身不知道什么样的代码有风险的话，那么Code Review也并不一定有效--换句话说，Code Review的效果与团队的代码水平息息相关。但是话说回来，在这种情况下，Coverity自动化的代码静态分析也可能不会用的太好。

总而言之，让研发人员修复Bug最好的办法是找到一个简单直接的方案，证明给程序员这是一个真正的Bug.....

如果您想使用Coverity，请直接联系邮箱Bao.Han@synopsys.com 或电话/微信13311307163 。