Line-level bug-finding power of static analysis rules: a case study of Teamscale 

Teamscale is a commercial static analysis tool (SAT) that analyzes source code without executing it to identify potential quality problems. In Teamscale, static analysis rules are referred to as checks, and each violation generates a report referred to as a finding. Its 232 default Java checks can produce large numbers of findings in large projects, making review prioritization necessary under limited inspection budgets. Although Teamscale assigns severity levels to its checks—red (high) and yellow (low)—their line-level bug-finding power has not been systematically investigated. This study evaluates the line-level bug-finding power of Teamscale checks through the findings they report, derives an empirically grounded check ranking, examines whether red-severity checks exhibit stronger bug-finding power, and investigates whether ranked check orderings help practitioners detect more bugs under the same fixed inspection budget. We conducted an empirical study on 17 Apache Software Foundation (ASF) projects comprising 134 releases. To rank Teamscale checks by their line-level bug-finding power, we considered three types of check-ranking methods. We then compared these methods under a unified evaluation setting to identify the most reliable one in our experimental setting and used it to derive the final check ranking. Our analysis shows that checks related to code size and structural complexity demonstrate the strongest bug-finding power. We also find that red-severity checks generally exhibit stronger bug-finding power than yellow-severity checks, indicating that severity provides a coarse yet useful signal for inspection prioritization. More importantly, when findings are prioritized according to the ranked check ordering, practitioners can detect more buggy lines under the same fixed inspection budget. Our results suggest that prioritizing Teamscale findings according to the empirically derived check ranking can improve bug-finding efficiency under limited inspection budgets. The resulting global check ranking can serve as a reasonable default in practice. For projects where this global ranking aligns less well with project-specific bug patterns, project-specific recalibration may still be beneficial when sufficient local history is available.