Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>The first thing to do is tweak the heck out of your analysis settings; Coverity support probably left you with a fairly generic configuration. </p> <ul> <li>Triage a representative sample of the defects, and if a checker doesn’t seem to be producing a lot more signal than noise, turn it off for now. (Most of Coverity’s checkers are good, but nobody’s perfect, and it sounds like you need to do some ruthless prioritization.) <ul> <li>In the long run, turn some of those checkers back on, but mark them in your reporting as low priority. (This is harder than it should be; I’ve long argued that Coverity needs to read a couple of papers on defect ranking by somebody called Dawson Engler. :-)</li> <li>In the even longer run, try the checkers that are disabled by default; some of them find impressive bugs. And parse warnings are surprisingly useful, though you do need to turn off some bogus ones.</li> </ul></li> <li>Be cynically realistic about which part of your codebase you’re actually going to fix soon. Use components to skip analysis on the code you’re not going to fix defects in, at least for now. (For instance, in theory, if your product includes third-party code, you’re responsible for its quality and should patch bugs in it. In practice, such bugs rarely get fixed. And if it’s mature third-party code, the false positive rate will be high.) <ul> <li>Setting up components and exclusion is tricky, but once it’s done, they work well—one of my negative look-ahead regexes had over a hundred disjuncts.</li> <li>Components also help with assigning individual responsibility for defects, which I’ve found to be crucial to getting them fixed.</li> </ul></li> <li>Set up a report for only new defects, and have people watch that URL. New defects are in active code, and it’s easier to get started with a No New Warnings policy.</li> </ul> <p>Let me end with a couple of disclaimers: </p> <ul> <li>You may want to re-ask this question in the Coverity support forum (<a href="http://forums.coverity.com/" rel="nofollow noreferrer">http://forums.coverity.com/</a>), which isn’t very active, but where we don’t have to worry about violating the NDA. I’ve got a list there of the checkers I found worth enabling.</li> <li><p>I do this for a living, and maybe you want to hire us (<a href="http://codeintegritysolutions.com/" rel="nofollow noreferrer">http://codeintegritysolutions.com/</a>); I’m giving a talk on this subject at Stanford today. Hiring a consultant to do the tuning makes a lot of sense; having somebody outside the company doing the triaging is trickier. Having an outsider do the fixes is trickier still; learning from your mistakes is even more important than fixing them.</p> <ul> <li>I’ve expanded this a bit with some parts of my Stanford talk, for our corporate blog: <a href="http://codeintegrity.blogspot.com/2010/01/handling-embarrassment-of-riches.html" rel="nofollow noreferrer">http://codeintegrity.blogspot.com/2010/01/handling-embarrassment-of-riches.html</a>.</li> </ul></li> </ul>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload