尚未解决的编译器警告百分比中是否有任何数据实际上导致错误？

Question

由于大量代码被重复使用，因此遇到了许多程序员来使用现有代码，在其中他们遇到了很多编译器警告。要解决这些编译器警告，确实需要付出很多努力，但这似乎并不总是可用。为了更好地了解解决编译器警告如何对软件开发的总体效率有所贡献，我对显示未解决的编译器警告的百分比在开发后期会导致实际运行时错误的数据非常感兴趣。

是否有人知道这类数据以及在哪里找到？

Answer 1

在我工作过的一家公司中，在决定采取一致的努力将警告降低到0之前，我们已经咳嗽了200万行代码，使警告扩展到大约16000条。一个月左右。

我们统计了发现的警告实际上标记了多少个错误。一些是主观的，许多是次要的，随着我的前进，我没有确切的数字。但是，在一个带有1050个警告的模块中，大约有100个问题被标识为“影响服务”的错误。但是，这是一个核心模块。

--edit--- 关于Defect Free软件的这篇文章对此很有趣。

然后在此页面上：

在本文中，作者引用了发表在《软件评估，基准和最佳实践》（Jones，2000年）中的“大量实证研究”中的数据。在SIE CMM级别1（听起来像是此代码的级别）上，可以预期每个功能点的缺陷率为0.75。我将留给您确定功能点和LOC在代码中的关系-您可能需要度量工具来执行该分析。

Code Complete中的Steve McConnell 引用了对同一团队开发的11个项目的研究，其中5个没有代码审查，6个有代码审查。未经审查的代码的缺陷率是每100 LOC 4.5，对于审查的缺陷率为0.82。因此，在此基础上，在没有其他任何信息的情况下，您的估算似乎是合理的。但是，我必须假设该团队具有一定的专业水平（仅出于他们认为需要进行研究的事实），并且他们至少会听取警告。您的缺陷率可能更高。

可能是您可以学习的最有价值的课程-将所有警告视为错误，直到被证明没有错误为止，甚至修复它们。