Static Analysis Tools: When Less Is More

Static code analysis (or static analysis) is a software testing activity in software development, in which the source code is analyzed for constructs known to be associated with software errors or security vulnerabilities. When a high-risk construct is detected, the static analysis tool reports a violation for the developer to view and remediate.

Running static analysis on the desktop will provide some benefits and may work for small teams or projects; however, in large organizations, static analysis should also be automated as part of nightly builds and continuous integration. When implemented as an integral part of the development process, analyzing your code with static analysis provides a number of benefits. Consistently running static analysis from the early stages of the project enables you to find and fix systemic defects when the cost of remediation is at its lowest. Static code analysis helps you find and fix defects early, which can prevent the recurrence of systemic defects downstream. With a policy of early detection, you can more easily implement a policy of defect prevention, which reduces the rate of defects over the development lifecycle.

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 recom­mend 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 suppres­sion 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