Want to see Parasoft in action? Sign up for our Monthly Demos! See Demos & Events >>
Want to see Parasoft in action? Sign up for our Monthly Demos! See Demos & Events >>
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.
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 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).
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:
To learn more about Parasoft static analysis, go to: https://www.parasoftchina.cn/solutions/static-code-analysis
Parasoft’s industry-leading automated software testing tools support the entire software development process, from when the developer writes the first line of code all the way through unit and functional testing, to performance and security testing, leveraging simulated test environments along the way.