Static analysis captures the current state of your code base and helps you answer key questions about the quality, security and maintainability of your software project.
Think Magic 8 Ball with build omniscience and powerful reporting tools. OK, maybe Magic 8 Ball isn’t a good analogy.
Answers to what questions, you ask? One we often hear from customers is: Where do I start?
A good place to start is a report that captures the distribution of defect types from your current build. For example, we recommend that our customers glance over the Top 10 Issues report in our web-based build reporting tool, Klocwork Review while indulging in their morning cup of coffee:
With this build snapshot and your caffeine jolt, you can quickly identify defects of interest to your organization, such as null pointer dereferences and memory leaks. If you wish, you can set up filters (we call views) to show only these defect types in your report.
Your next step is to get your developers using static analysis on their desktops to prevent the injection of these high-priority defects into the build in the first place.
Once a policy of pre-checkin static analysis usage is put in place, pay attention to new defects injected into the build from that point on. If you see a spike in new defects, then investigate.
The magnitude of that y-axis is not what matters most; it’s the overall trend that counts.
For my next post, I’ll take a look at reports that track your cost of ownership and show you what success looks like.