Do you want to clean up your static analysis practices ？ First , Remove the clutter that makes it difficult for you to focus on issues of real concern . Next , Stimulate your practice by expanding the scope of your activities to add 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 alert to all alarms （ Include alerts that you think are critical ） Insensitivity ？
Whatever static analysis tool you use , Can be passed through the following 10 There are two ways to update the existing static analysis implementation .
skill 1： Disable static analysis rules for violations that you have not yet resolved
Checking a lot of rules doesn't get the best from static analysis ROI The secret of . actually , in many instances , The opposite is true . If you focus on a minimal but meaningful set of rules , Then static analysis can actually provide better results .
When you perform static analysis , It's like you have experienced developers on the shoulders of inexperienced developers , And give him tips when writing code . If experienced developers are constantly picking on every few lines of code , Then inexperienced developers will soon be at a loss , And start filtering out all the good and bad suggestions . however , If an experienced developer focuses on one or two problems that he knows can lead to serious problems , Then inexperienced developers are likely to remember the advice given , Start writing better code , And I appreciate receiving this feedback .
So is static analysis . If you keep it manageable and meaningful , So you'll end up teaching your developers more , And let them focus less on the process . You want to follow a small set of rules , Or not following the big rules ？ If you really don't want developers to clean up violations immediately after receiving a report , Then you may want to seriously consider disabling the rule .
skill 2： Disable static analysis rules that cause excessive noise
If a particular rule is repeatedly violated , Now is a good time to reevaluate whether you really want to continue checking the rule . Too many violations indicate that developers are not writing code in the way required by the rules . Persuading them to change their coding habits can be very difficult .
How do you determine if solving a problem is worth the effort ？ First , Try to remember why you should check the problem first . You chose it because it seems to be a good way to solve the problems you encounter in the field ？ As part of regulatory compliance ？ Or just because the vendor enabled it by default ？ Suppliers usually refer to each rule in their rule description . Reading these descriptions can help you determine if the rule really suits your project and goals .
Next , See if there are other ways to achieve the desired effect . Are there any more specific rules ？ Is there a way to fine tune the rule parameters , So it doesn't trigger very often ？（ About techniques 6 For more information ）. You can even consider writing your own more appropriate rules , Or let the vendor create custom rules for you .
If you're still interested in checking the rule after reexamining its benefits and exploring alternatives , Please get some development feedback , To understand what might be involved in following this rule . then , You can use this feedback to determine if it's really worth asking developers to comply with this rule . If it looks like a lot of work , But it didn't work , Please continue and disable the rule .
skill 3： Use inhibition to allow violations in certain situations
In some cases , You may follow the rules , But in some cases, you want to allow immunity . for example , Maybe you have a rule , Requires some extra level of validation to be performed in the code . Suppose you have a specific way to use performance critical code , This method is called hundreds of times per minute , And you have verified that the appropriate level of validation has been performed before calling this particular method . perhaps , Let's assume that you are analyzing a serious problem , That is, you think 100％ Make sure you can't use it in an integrated application . This is where repression comes in .
For situations that need to be checked , Inhibition is the best choice , But you don't care about problems reported in special cases . Use inhibition , You can continue to examine the key issues , Instead of receiving repeated messages about intentional violations of the rules . If you don't want to receive an error message for violating a specific rule , It is recommended that you disable the rule completely （ Please refer to No 1 spot ）.
Usually , You can use the static analysis tool GUI, The configuration file or source code itself defines suppression . When defining suppression in source code ：
- You make sure that the same suppression is applied when you or team members analyze the code .
- You can add code comments that explain each inhibition , So when you or a team member view or modify the code , The reason for every inhibition is always clear .
- You can get to the file , Fine grained control of which rules are enforced at the class or row level .
Usually , You can prohibit violations of certain rules , All violations in multiple rules or specific categories . You can also remove parts of the code from all static analysis （ And more after that ）.
skill 4： Stop analyzing problematic files or blocks of code
Sometimes , For some documents （ for example , Automatically generated files or old files you don't intend to touch ） Static analysis just doesn't make sense . In these cases , Analysis of these documents should be prevented . This is another way to ensure that your results are not confused 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 just the files you want to check . perhaps , You can configure the tool to skip files that contain specific comments , for example , Comments indicate automatically generated code .
Other inspection highlights include ：
- Add tags to indicate specific code blocks to check in other exemption files .
- Exclude some methods from the file , Otherwise it will be analyzed .
- Check only files that have not been added or modified since a deadline .
- Only check in “ Closing date ” Files added or modified after or within a specific number of days .
skill 5： Inform the static analysis tool supplier of the violation rules that result in false positives
In pattern based static analysis , False positives are violations of rules , These errors are incorrectly reported when the code actually follows the rules . for example , If the rule says you have unclosed resources （ for example JDBC Connect ）, The connection is actually closed , So this is a false positive . If you really want to follow these rules , So spring cleaning is a good time to finally report it to the supplier .
Please note that , If you go down this road , You need to make sure you're seeing false positives , Instead of 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 case . This kind of news is not a false positive , under these circumstances , 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 an error message , It should be very helpful to find out and correct most of the problems .
skill 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're checking one Android The rules , The rule requires “ Make sure the widget doesn't take too long to update .”
When using the default settings , This rule will recognize that the widget is set to update every day 4 Code more than times . It marks the label [appwidget-provider] The elements in [android：updatePeriodMillis] Set to less than 21600000 The number of code to achieve .
Suppose that getting updated information is critical to your application , So you're willing to sacrifice some battery power for more frequent updates . under these circumstances , You may only want to update more than 8 It's time to be warned . So , You can simply put “ Maximum update time （ In Milliseconds ）” Rule parameters from 21600000 ms（6 Hours ） Updated to 10800000 ms（3 Hours ）.
Such as technique 2 Described , If the rule does not have the required parameters , You can write a new rule , You can also let the supplier （ Or consultant ） Write custom rules for you .
skill 7： Map static analysis rules to your own terms
Are you tired of Security 123 Equate to ACME 3.1 guide ？Performance 987 and Performance 567 Whether it's all with your ACME 5.6 The criteria are relevant ？ Even if your tool says thread 123 The severity of the problem is 4, Does your organization still think that violating this rule is a very serious defect ？
If so ,“ Spring cleaning ” Is to map the static analysis rule set of suppliers to match the team and / Or different strategies defined by the organization . Most static analysis tools allow you to customize the severity of a rule ,ID And name , And create new rule categories , So that the deployed rules exactly match the contents of your own coding policy document .
If your organization performs static analysis as part of the compliance effort , This will make your report easier .
skill 8： Review and clarify your static analysis strategy
Every team has a policy , Whether formally defined or not . You'd better code the process and formalize it . After all , It's much easier to identify and diagnose problems with a formal policy than without a written policy .
Ideally , You want your policies to be relevant to your current problems （ and / Or committed to prevention ） Direct correlation . thus , There is a good basis for the overall policy and the specific implementation mode .
With these goals in mind , The policy should clarify ：
- Which teams need to perform static analysis
- Which projects need static analysis
- What rules are needed
- To what extent
- When is repression allowed
- When to resolve violations in legacy code
- Whether there is code attached that violates static analysis
skill 9： Expand the scope of analysis
After clearing the mess , You will be able to use teams for static analysis , There are few problems reported , And the reported problems have been cleaned up in time , You can go on to the next step , And expand the scope of inspection .
One way to expand the scope of the inspection is to add more rules that are critical to the project and goals . To zero the rule to be added , Please consider it ：
- It seems that there are rules to prevent on-site reporting problems that take up a lot of team resources ？
- If you're going to start following industry or organization specific compliance plans soon , So what rules can help you get started quickly ？
- When a rule set is first created or finally optimized , Which rules are you least willing to delete ？
Another way to increase the scope of the check is to check other code . If you initially set the static analysis tool to skip old files （ for example , Skip starting static analysis “ end ” All files not added or modified after date ）, You may need to consider moving back to that deadline , Or cancel a total of .
skill 10： automation ！ automation ！ automation ！
The more you can automate the static analysis process , The less the burden 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 team and across the organization .
Many organizations follow a multi-level automation process . Every day , When developers are in IDE When dealing with code in , He or she can run the analysis on demand - Or configure automatic analysis to run continuously in the background （ It's like a spelling check ）. Developers clear these violations before adding new or modified code to source control .
then , The server based process checks again to see if the checked in code base is clean . This analysis can be part of the ongoing integration that continues every night , wait , To make sure there are no leaks through the cracks . Through this server based process , It's 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 code that developers write UI. E-mail enforces additional steps , This leads to the loss of violations , Waste time looking for the right line in the file and dissatisfaction with the coder , They feel like they've done something else out of the routine .
To further optimize the workflow through automation , Please consider it ：
- Automatically route each reported problem directly to the responsible Developer , And customize the issue priority to suit your policy priority , To ensure timely resolution of the most critical issues .
- Centralized configuration management , To ensure that the rule set is applied consistently , And it can be updated effortlessly as priorities and processes evolve .
- Use automatic as much as possible “ Quick fix ” restructure , To help the team correct violations as soon as possible .