Do you want to clean up your static analysis practice? First, clean up the clutter that makes it difficult for you to focus on the issues you really care about. Next, stimulate your practice by expanding the scope of activities to increase the value to the organization.
Is your development team overwhelmed by the increasing number of violations in static analysis tools? Does the high level of noise generated by your current static analysis configuration make the team insensitive to all alarms (including those that you consider critical issues)?
No matter which static analysis tool you use, you can update the existing static analysis implementation through the following 10 methods.
Tip 1: Disable static analysis rules for violations that you have not yet resolved
Checking a large number of rules is not the secret to obtaining the best ROI through static analysis. In fact, in many cases, the opposite is true. If you focus on the smallest but meaningful set of rules, static analysis can actually provide better results.
When you perform static analysis, it is as if you put an experienced developer on the shoulders of an inexperienced developer and provide him with hints when writing code. If experienced developers are constantly picky about every few lines of code, then inexperienced developers will quickly be overwhelmed and begin to filter out all good and bad suggestions. However, if an experienced developer focuses on one or two problems that he knows may cause serious problems, then the inexperienced developer is likely to remember the advice given, start writing better code, and Appreciate receiving this kind of feedback.
The same is true for static analysis. If you keep it manageable and meaningful, you will eventually teach your developers more and make them less refocused on the process. Do you want to follow a small set of rules, or do you not follow a large set of rules? If you really don’t want the developer to clear the violation immediately after receiving the report, then you may want to seriously consider disabling the rule.
Tip 2: Disable static analysis rules that cause too much noise
If a particular rule is repeatedly violated, now is a good opportunity to reassess whether you really want to continue to check the rule. Too many violations indicate that developers have not written code in the way required by the rules. Persuading them to change their coding habits may encounter great resistance.
How do you determine whether solving the problem is worth the effort? First, try to remember why the problem was checked in the first place. You chose it because it seems to be a good way to solve the problems you encountered in the field? As part of regulatory compliance work? Or is it just because the vendor has enabled it by default? Suppliers usually provide references for each rule in their rule descriptions. Reading these descriptions can help you determine whether the rule is indeed suitable for your project and goals.
Next, see if there are other methods that can achieve the desired results. Are there other more specific rules? Is there a way to fine-tune the rule parameters so that they do not trigger frequently? (More information on technique 6). You can even consider writing your own more suitable rules, or let the supplier create custom rules for you.
If you are still interested in checking this rule after rechecking the benefits of this rule and exploring its alternatives, please get some development feedback to understand what might be involved in following this rule. You can then use this feedback to determine whether it is indeed worth asking developers to follow this rule. If it looks like a lot of work, but has little effect, please go ahead and disable the rule.
Tip 3: Use suppression to allow violations under certain circumstances
In some cases, you may follow the rules, but want to allow exemptions in some cases. For example, maybe you have a rule that requires some extra level of verification in your code. Suppose you have a specific method of using performance-critical code that is called hundreds of times per minute, and you have verified that you have performed the appropriate level of verification before calling this specific method. Or, suppose that flow-based analysis is warning you of a serious problem, that you think it is 100% certain that it cannot be used in an integrated application. This is where inhibition comes in handy.
For situations that need to be checked, suppression is the ideal choice, but you don't care about the problems reported in special circumstances. With suppression, you can continue to check for critical issues without receiving repeated messages about deliberate rule violations. If you do not want to receive an error message for violating a specific rule, it is recommended that you disable the rule completely (see point 1).
Usually, you can define suppression from the static analysis tool GUI, configuration file or the source code itself. When defining suppression in the source code:
- You make sure that the same suppression is applied when you or a team member analyze the code.
- You can add code comments that explain each suppression so that when you or a team member view or modify the code, the reason for each suppression is always clear.
- You can gain fine-grained control over which rules are enforced at the file, class, or line level.
Generally, you can prohibit violations of a specific rule, multiple rules, or all violations in a specific category. You can also exempt certain parts of the code from all static analysis (more on this later).
Tip 4: Stop analyzing the problematic file or code block
Sometimes, it just doesn't make sense to perform static analysis on certain files (for example, auto-generated files or old files you don't plan to touch). In these cases, analysis of these files should be prevented. This is another way to ensure that your results are not messed up by a series of violations that you do not intend to solve.
There are several ways to do this. You can set a path filter to exclude files you don't want to check, or include only files you want to check. Alternatively, you can configure the tool to skip files that contain specific comments, for example, comments indicating automatically generated code.
Other inspection highlights include:
- Add flags to indicate specific code blocks to be checked in other exempt documents.
- Exclude some methods in the file, otherwise they will be analyzed.
- Only check files that have not been added or modified since a certain deadline.
- Only check files added or modified after the "expiration date" or within a certain number of days.
Tip 5: Notify the static analysis tool supplier of the breaking rules that lead to false positives
In pattern-based static analysis, false positives are violations of rules, and these errors are reported incorrectly when the code actually follows the rules. For example, if the rule says that you have an unclosed resource (such as a JDBC connection), then the connection is actually closed, then this is a false positive. If you do follow such rules, then Spring Cleaning is a good time to report it to the supplier.
Please note that if you follow this path, you need to make sure that what you are seeing is a false positive, rather than simply following the rules you don’t like. Developers often refer to messages as "false positives" because they don't like the rule or don't feel that the rule applies in this situation. Such messages are not false positives, in this case your supplier will not be able to help you.
However, if you can reduce a simple test case that shows how a particular rule actually gets the error message, you should find that most vendors are very helpful in correcting the problem.
Tip 6: Customize static analysis rule parameters to suit your needs
Another way to reduce the noise factor is to customize the rule parameters. For example, suppose your team is doing Android development, and you are reviewing an Android rule that requires "make sure that widgets are not updated for too long."
When using the default settings, this rule will identify codes that set the widget to update more than 4 times a day. It is implemented by marking the code that sets the element [android:updatePeriodMillis] in the tag [appwidget-provider] to a number less than 21,600,000.
Suppose that getting updated information is critical to your application, so you are willing to sacrifice some battery power for more frequent updates. In this case, you may only want to update more than 8 times a day before being warned. To do this, you can simply update the "Maximum Maximum Update Time (in milliseconds)" rule parameter from 21600000 ms (6 hours) to 10800000 ms (3 hours).
As mentioned in Tip 2, if the rule does not have the required parameters, you can write a new rule, or you can have the supplier (or consultant) write a custom rule for you.
Tip 7: Map static analysis rules to your own terms
Are you tired of Security 123 being equivalent to ACME 3.1 guidelines? Are both Performance 987 and Performance 567 related to your ACME 5.6 guidelines? Even if your tool says that thread 123 has a severity of 4, does your organization still consider that violation of this rule is a very serious flaw?
If so, "spring cleaning" is a good time to map the supplier's static analysis rule set to match the different strategies defined by the team and/or organization. Most static analysis tools allow you to customize the severity, ID, and name of the rule, and create new rule categories so that the deployed rules match the content of your own coding strategy documents.
If your organization performs static analysis as part of compliance work, this will make your reporting easier.
Tip 8: Re-examine and clarify your static analysis strategy
Every team has a policy, whether it is formally defined or not. You'd better code the process and formalize it. After all, it is much easier to identify and diagnose problems with a formal policy than without a written policy.
Ideally, you want your policies to be directly related to the problems you are currently experiencing (and/or commitment to prevention). In this way, the overall policy and specific implementation methods have a good basis.
With these goals in mind, the policy should state:
- Which teams need to perform static analysis
- Which projects need static analysis
- What rules are needed
- What is the requirement
- When to allow suppression
- When to resolve violations in legacy code
- Is there any code that violates static analysis?
Tip 9: Expand the scope of analysis
After the chaos is cleared, you will be able to use the team for static analysis. There are few problems reported, and the reported problems have been cleaned up in time. You can proceed to the next step and expand the scope of inspection.
One way to expand the scope of inspection is to add more rules that are critical to the project and goals. To zero out the rules to be added, consider:
- What rules seem to prevent on-site reporting of problems that consume a lot of team resources?
- If you are about to start complying with industry or organization-specific compliance programs, what rules can help you get started quickly?
- When first creating or finally optimizing a rule set, which rules are you least willing to delete?
Another way to increase the scope of inspection is to inspect other codes. If you initially set the static analysis tool to skip old files (for example, skip all files that were not added or modified after the "cut-off" date to start static analysis), you may want to consider moving back to that cut-off date, or canceling the total.
Tip 10: Automation! automation! automation!
The more you can automate the static analysis process, the less burden it puts on developers and distract them from the more challenging tasks they really like. In addition, the added automation capabilities will help you achieve consistent results across the entire team and the entire organization.
Many organizations follow a multi-level automated process. Every day, when the developer is working on the code in the IDE, he or she can run the analysis on demand-or configure the automatic analysis to run continuously in the background (just like a spell check). Developers clear these violations before adding new or modified code to source control.
Then, the server-based process again checks whether the checked-in code base is clean. This analysis can be used as part of continuous integration that is ongoing nightly, etc., to ensure that no loopholes pass through the cracks. With this server-based process, it is important to avoid using the old paradigm of sending email to developers. Part of an effective workflow is to distribute error messages to the same UI where the developer writes the code. E-mail enforces additional steps, resulting in loss of violations, wasting time in finding the correct lines in the file, and dissatisfaction with coders who feel like they have done other things outside of regular procedures.
To further optimize your workflow through automation, consider:
- Automatically route each reported issue directly to the responsible developer, and customize the issue priority to suit your strategic priority to ensure that the most critical issues are resolved in a timely manner.
- Centralized configuration management to ensure that rule sets are applied consistently and can be updated effortlessly as priorities and processes evolve.
- Use automatic "quick fix" refactoring as much as possible to help the team correct the violation of the rules as soon as possible.