由于重复使用了大量代码，因此遇到许多程序员使用现有的代码，在这些代码中他们会遇到许多编译器警告。要解决这些编译器警告确实需要付出努力，而这似乎并不总是可用。为了更好地了解解决编译器警告如何有助于提高软件开发的总效率，我对数据非常感兴趣，显示未解决的编译器警告的百分比会导致开发后期的实际运行时错误。
有人知道这些数据以及在哪里找到？
答案 0 :(得分：4)
在我工作的一家公司，我们有两百万行代码（咳嗽）让警告扩展到大约16 000，然后我们决定全力以赴地将它们减少到0。达到目标非常令人满意。大约一个月后。
我们保留了我们发现的警告实际标记的错误数量。有些是主观的，很多是次要的，我没有确切的数字，因为我继续前进。然而，在一个包含约1050个警告的模块中，大约有100个问题被识别为“服务影响”错误。这是一个核心模块。
关于Defect Free软件的- edit-- - this article是一个有趣的读物。
然后在this page：
在this article中，作者引用了Software Assessments, Benchmarks, and Best Practices (Jones, 2000)中发表的“大量实证研究”中的数字。在SIE CMM Level 1，听起来像这个代码的级别，可以预期每个功能点的缺陷率为0.75。我将留给您确定代码中函数点和LOC的关系 - 您可能需要一个度量工具来执行该分析。
Steve McConnell代码完成cites a study由同一团队开发的11个项目，5个没有代码审查，6个代码审查。未经审核的代码的缺陷率为每100 LOC 4.5个，并且对于审查的代码为0.82。所以在此基础上，如果没有任何其他信息，您的估计似乎是公平的。但是，我必须在这个团队中承担一定程度的专业精神（仅仅因为他们感到需要进行研究），并且他们至少会接受警告;你的缺陷率可能会高得多。
可能是您可以学到的最有价值的教训 - 将所有警告视为错误，直到证明不是这样，即便如此，也要修复它们。
答案 1 :(得分：1)
调查这个奇妙的C4930警告：
CSomethingSwitcher switcher(); //C4930 - unused function prototype
//blahblahblah
显然，switcher对象不会被创建，程序行为可能会被改变。你容忍这种缺陷的百分比是多少？
作为user Ed Guiness points out，每个警告都可能表示存在真正的问题。