Are you confident that the high level of noise being generated by your current static analysis configuration hasn't desensitized the team to all alerts—including those for issues that you consider critical?
The first step to optimizing your static analysis is clearing out the clutter that's making it difficult to zero in on the issues you truly care about. The second is invigorating your initiative by expanding its scope in ways that increase its value to your organization.
In this series of blogs, we'll look at ways to freshen up your static analysis implementation. Let's begin by looking at 2 ways to scrub your static analysis rule set.
Disable static analysis rules you're not committed to enforcing right now
Checking a lot of rules is not the secret to achieving the best ROI with static analysis. In fact, in many cases, the reverse is true. Static analysis actually delivers better results if you focus on a minimal yet meaningful set of rules.
When you perform static analysis, it's like you're having an experienced developer stand over the shoulder of an inexperienced developer and give him tips as he writes code. If the experienced developer is constantly harping on nitpicky issues in every few lines of code, the junior developer will soon become overwhelmed and start filtering out all advice—good and bad. However, if the experienced developer focuses on one or two issues that he knows are likely to cause serious problems, the junior developer is much more likely to remember what advice he was given, start writing better code, and actually appreciate receiving this kind of feedback.
It's the same for static analysis. If you keep it manageable and meaningful, you'll end up teaching your developers more and having them resent the process much less. Would you rather have a small set of rules that are followed or a large set that is not? If you don't truly expect the developers to clean violations of a rule as soon as they are reported, you might want to seriously consider disabling that rule.
Disable static analysis rules causing too many violations
If a particular static analysis rule is being violated repeatedly, now is a good opportunity to re-evaluate whether you really want to continue checking that rule. An excessive number of violations indicates that the developers are not writing code in the way that the rule requires. Convincing them to change their coding habits could meet a fair amount of resistance.
How can you determine if pressing the issue will be worth the effort? First, try to remember why you started checking for that problem in the first place. Did you select it because it seemed like a good way to address issues you're experiencing in the field? As part of your regulatory compliance efforts? Or simply because it was enabled by default by the vendor? Vendors typically provide the reference for each rule in their rule descriptions. Reading these descriptions can help you determine if the rule is really a good match for your projects and goals.
Next, see if there's an alternative way to achieve the desired result. Is there an alternative rule that's more specific? Is there a way to fine-tune the rule parameters so that it's not firing so often? (More on this in another post). You might even consider writing your own rule that will be a better fit— or have the vendor create a custom rule for you.
If you're still interested in checking this rule after re-examining its benefits and exploring its alternatives, get some development feedback on what would be involved in following this rule. You can then use this feedback to determine if it's truly worth it to require developers to follow this rule. If it looks like a lot of work for little benefit, go ahead and disable the rule.
Image Credit: Clearly Ambiguous