Are there any data on % of unsolved compiler warnings that actually leads to an error?
Since a lot of code is re-used, many programmers are encountered to work with existing code in which they encounter lot's of compiler warnings. To solve these compiler warnings does take effort which seems not always available. To get better insight on how solving compiler warnings contributes to the total efficiency in software development I am very interested in data showing what % of unsolved compiler wa开发者_JAVA技巧rnings results in real run-time bugs in later stages of the development.
Is anyone aware about these kind of data and where to find?
At a company I worked for, in two million lines of code we had (cough) let the warnings extend to around 16 000 before we decided to put in a concerted effort to reduce them to 0. It was quite satisfying to reach that after a month or so.
We kept stats on how many bugs we found that were actually flagged by the warnings. Some were subjective, many were minor, and I don't have the exact number handy as I've moved on. However in the one module with ~1050 warnings, there were around 100 issues identified as 'service affecting' bugs. This was a core module though.
--edit-- - this article on Defect Free software is an interesting read on the matter.
Then on this page:
In this article, the author cites figures from a "a large body of empirical studies", published in Software Assessments, Benchmarks, and Best Practices (Jones, 2000). At SIE CMM Level 1, which sounds like the level of this code, one can expect a defect rate of 0.75 per function point. I'll leave it to you to determine how function points and LOC may relate in your code - you'll probably need a metrics tool to perform that analysis.
Steve McConnell in Code Complete cites a study of 11 projects developed by the same team, 5 without code reviews, 6 with code reviews. The defect rate for the non-reviewed code was 4.5 per 100 LOC, and for the reviewed it was 0.82. So on that basis, your estimate seems fair in the absence of any other information. However I have to assume a level of professionalism amongst this team (just from the fact that they felt the need to perform the study), and that they would have at least attended to the warnings; your defect rate could be much higher.
Probably the most valuable lesson you can learn - treat all warnings as bugs, until proven otherwise, and even then, fix them.
look into this marvelous C4930 warning:
CSomethingSwitcher switcher(); //C4930 - unused function prototype
//blahblahblah
obviously the switcher
object will not have been created and program behavior will likely be altered. What percentage of such defect will you tolerate?
As user Ed Guiness points out, every warning might signal of a real problem.
精彩评论