Static Analysis Tools: When Less Is More
January 31, 2013
3 min read
However, during the adoption of static analysis into a project, it can sometimes be overwhelming. If you have a large code base, static analysis tools can report a large number of violations This post discussed two tips for slimming down static analysis violation reports.
Tip 1: Use static analysis tool suppressions for exemptions in specific situations
In some cases, you might be committed to following a static analysis rule, but want to allow exemptions under certain circumstances. For example, maybe you have a rule that requires some extra level of validation to be performed in the code. Assume you have a certain method with performance-critical code that is called hundreds of times a minute—and you’ve already verified that an appropriate level of validation is performed before this particular method is called. Or, assume that flow-based analysis is warning you about a serious problem in a path that you are 100% certain cannot be taken in the integrated application. This is where static analysis suppressions come in handy.
Suppressions are ideal for situations when you want to check for something, but you don’t care about reported problems under exceptional situations. With suppressions, you can continue checking for a critical issue without receiving repeated messages about your intentional static analysis rule violations. If you do not want to receive error messages for any violations of a specific rule, we recommend that you disable the rule altogether (see our earlier blog on scrubbing your static analysis rule set).
You can typically define suppressions from the static analysis tool GUI, a configuration file, or the source code itself. When suppressions are defined in source code:
- You ensure that the same suppressions are applied whenever you or a team member analyzes that code.
- You can add code comments explaining each suppression so the reason for each suppression is always clear when you or team members are reviewing or modifying the code.
- You gain fine-grained control over which rules are enforced at the file, class, or line level.
You can typically suppress violations of a specific rule, a number of rules, or all violations in a specific category. You could also exempt certain sections of code from all static analysis (more on this in the next tip).
Tip 2: Stop your static analysis tool from checking problematic files or chunks of code
Sometimes it just doesn’t make sense to run static analysis tools on certain files—for instance, automatically-generated files or legacy files that you don’t plan on touching. In these cases, you should prevent these files from being analyzed. This is yet another way to ensure that your results aren’t cluttered with a bunch of violations you’re not planning on fixing.
There are a few ways to do this. You could set up path filters to exclude files you don’t want to check or include only the ones you do want to check. Or, you could configure your tool to skip files that contain a certain comment—such as a comment indicating automatically-generated code.
Other ways to focus your static analysis tool’s checking include:
- Adding markers to indicate specific blocks of code you want checked within otherwise exempted files.
- Excluding certain methods within files that are otherwise analyzed.
- Checking only files that were not added or modified since a certain cutoff date.
- Checking only files that were added or modified after a “cutoff date” or within a certain number of days.
To learn more about Parasoft static analysis, go to: https://www.parasoft.com/solutions/static-code-analysis