Automatic static analysis tools (ASATs) detect source code violations to static analysis rules and are usually used as a guard for source code quality. The adoption of ASATs, however, is often challenged because of several problems such as a large number of false alarms, invalid rule priorities, and inappropriate rule configurations. Research has shown that tracking the history of the violations is a promising way to solve the above problems because the facts of violation fixing may reflect the developers' subjective expectations on the violation detection results. Precisely identifying the revisions that induce or fix a violation is however challenging because of the imprecise matching of violations between code revisions and ignorance of merge commits in the maintenance history. In this paper, we propose ViolationTracker, an approach to precisely matching the violation instances between adjacent revisions and building the life cycle of violations with the identification of inducing, fixing, deleting, and reopening of each violation case. The approach employs code entity anchoring heuristics for violation matching and considers merge commits that used to be ignored in existing research. We evaluate ViolationTracker with a manually-validated dataset that consists of 500 violation instances and 158 threads of 30 violation cases with detailed evolution history from open-source projects. Violation Tracker achieves over 93 % precision and 98 % recall on violation matching, outperforming the state-of-the-art approach, and 99.4 % precision on rebuilding the histories of violation cases. We also show that ViolationTracker is useful to identify actionable violations. A preliminary empirical study reveals the possibility to prioritize static analysis rules according to further analysis on the actionable rates of the rules.

Automated static analysis tools (ASATs) have become an integrated part of the software development workflow in many projects. While developers benefit from these tools to deliver quality code conforming to the pre-defined static analysis rules, it has been reported that many ASATs are underused. A number of detected violations are overlooked by developers due to false alarms or unactionable alerts. Despite of existing studies on the fixes of static analysis violations, there is still a gap in collecting and understanding the fact that some types of violations are fixed more often and/or more quickly than other types. To fill this gap, we conduct a large-scale empirical study on 56,506,892 violations from 30 active, popular, and high-quality open-source Java projects with long evolution histories. All violations were traced between adjacent revisions before we filtrated the fixed violations out of the closed ones by considering the types of source code changes that closed the violations. We identified the violation types with the highest and lowest fix rates and those that were fixed the most timely and least timely, and further investigated the possible underlying reasons for the differences in fix rate and fix time. Our findings is helpful to characterize and understand developers’ considerations when fixing violations and provide practical implications for developers, tool builders and researchers to optimize the usage and design of ASATs.