Question

I do use static code analysis on a project with more than 100.000 lines of Java code for quite a while now. I started with Findbugs, which gave me around 1500 issues at the beginning. I fixed the most severe over time and started using additional tools like PMD, Lint4J, JNorm and now Enerjy.

With the more severe issues being fixed, there is a huge number of low severity issues. How do you handle these low priority issues?

• Do you try fixing all of them?
• Or only in newly written code?
• Do you regularly disable certain rules? (I found that I do on nearly any of the available tools).

And if you ignore or disable rules, do you document those? What do your managers say about “leaving some thousand low priority issues not fixed”? Do you use (multiple) tool specific comments in the code or is there any better way?

Answer 1

Keep in mind that static analysis is meant to generate a lot of false positives; this is the price you pay for generally avoiding false negatives. That is, they assume that you would much rather be told incorrectly that something looks suspicious (a false positive) instead of being told that something that’s actually a problem is perfectly fine (a false negative).

So in general, you should be configuring these tools rather than accepting the out-of-the-box defaults, which generate a lot of noise.

Do you try fixing all of them?

On projects where I have technical control, my standard modus operandi is to encourage a culture where people review of all new static analysis defects from our CI system. If we decline to fix enough defects over a period of time that are of a specific kind, we disable that rule since it’s become just noise. Every so often we’ll look at the disabled rules to make sure that they’re still relevant.

But once we’ve turned off the less effective rules, yes, we fix all the defects. If you think that something is a problem, you should fix it if the priority doesn’t exceed that of other things you have to do. Ignoring it is damaging to your team’s culture and sends the wrong message.

And if you ignore or disable rules, do you document those?

The rules file is part of our project, so a commit message is sufficient to document the fact that such-and-such rules were disabled in this commit.

What do your managers say about “leaving some thousand low priority issues not fixed”?

Nothing. We make sure that they understand what we’re doing and why, but they’re usually (rightfully so) focused on higher-level metrics, like velocity and overall project health.