我们的管理层最近一直在与一些销售C++ 静态分析工具的人交谈.当然销售人员说他们会发现大量的错误,但我持怀疑态度.
这些工具如何在现实世界中发挥作用？他们发现真正的错误吗？他们帮助更多初级程序员学习吗？
他们值得这么麻烦吗？
静态代码分析几乎总是值得的.现有代码库的问题在于它可能会报告太多错误,使其开箱即用.
我曾经做过一个项目,它有来自编译器的100,000多个警告......在该代码库上运行Lint工具没有意义.
使用Lint工具"正确"意味着购买更好的流程(这是一件好事).我所做的最好的工作之一是在一个研究实验室工作,我们不允许在警告中检查代码.
所以,从长远来看,这些工具是值得的.在短期内,将编译器警告转到最大值并查看其报告的内容.如果代码是"干净的",那么现在就是查看lint工具的时间.如果代码有很多警告...优先级并修复它们.一旦代码没有(或至少很少)警告,那么请查看Lint工具.
所以,Lint工具不会帮助一个糟糕的代码库,但是一旦你有一个好的代码库,它可以帮助你保持良好.
编辑:
对于100,000多个警告产品,它被分解为大约60个Visual Studio项目.由于每个项目都删除了所有警告,因此它被更改,以便警告是错误,这可以防止将新警告添加到已清理的项目中(或者更确切地说,让我的同事对任何已签入的开发人员发出正义的吼叫代码没有先编译它:-)
根据我与几位雇主的经验,Coverity Prevent for C/C++显然是值得的,即使在优秀的开发人员代码中也会发现一些错误,以及最糟糕的开发人员代码中的许多错误.其他人已经涉及技术方面,因此我将关注政治困难.
首先,代码最需要静态分析的开发人员最不可能自愿使用它.所以我担心你在实践和理论上都需要强有力的管理支持; 否则它可能最终只是一个清单项目,以产生令人印象深刻的指标而不会实际修复错误.任何静态分析工具都会产生误报; 你可能需要专门用一些人来减少他们的烦恼,例如,通过分类缺陷,优先考虑检查器,以及调整设置.(商业工具应该非常擅长不止一次出现误报;仅此一点可能是物有所值.)即使真正的缺陷也可能产生烦恼; 我对此的建议不用担心,例如,签到评论抱怨显然破坏性的错误是"次要的".
我最重要的建议是我的第一条法则的必然结果:首先考虑廉价镜头,然后看看你最糟糕的开发者那些痛苦明显的错误.其中一些甚至可能是由编译器警告发现的,但是很多错误可能会漏掉这些漏洞,例如,当它们被命令行选项抑制时.真正明目张胆的错误在政治上是有用的,例如,有一个最有趣的缺陷的十大列表,如果仔细使用,它可以精彩地集中思想.
它确实有帮助.我建议你试用一个试用版并运行你认为被忽略的代码库的一部分.这些工具会产生很多误报.一旦你了解了这些,你可能会发现缓冲区溢出或两个可以在不久的将来节省大量的悲伤.此外,尝试至少两个/三个品种(以及一些OpenSource的东西).
正如一对夫妇所说,如果你在大多数应用程序上运行静态分析工具,你会得到很多警告,其中一些可能是误报或可能不会导致可利用的缺陷.正是这种体验导致人们认为这些类型的工具是嘈杂的,也许是浪费时间.但是,有一些警告会突出显示可能导致安全性,可靠性或正确性问题的真实且潜在危险的缺陷,对于许多团队而言,这些问题对于修复很重要,并且几乎不可能通过测试发现.
也就是说,静态分析工具可能非常有用,但将它们应用于现有代码库需要一些策略.以下是一些可能对您有帮助的提示..
1)不要一次打开所有内容,决定一组初始缺陷,打开这些分析并在代码库中修复它们.
2)当您解决一类缺陷时,请帮助您的整个开发团队了解缺陷是什么,为什么重要以及如何编写代码来抵御该缺陷.
3)努力彻底清除那类缺陷的代码库.
4)一旦修复了这类问题,就引入一种机制来保持零问题状态.幸运的是,如果您在基线没有错误,确保不重新引入错误要容易得多.
京公网安备 11010802040832号 | 京ICP备19059560号-6 