A longitudinal study of static analysis warning evolution and the effects of PMD on software quality in Apache open sour
- PDF / 1,753,689 Bytes
- 56 Pages / 439.642 x 666.49 pts Page_size
- 36 Downloads / 171 Views
A longitudinal study of static analysis warning evolution and the effects of PMD on software quality in Apache open source projects Alexander Trautsch1
· Steffen Herbold1
· Jens Grabowski1
© The Author(s) 2020
Abstract Automated static analysis tools (ASATs) have become a major part of the software development workflow. Acting on the generated warnings, i.e., changing the code indicated in the warning, should be part of, at latest, the code review phase. Despite this being a best practice in software development, there is still a lack of empirical research regarding the usage of ASATs in the wild. In this work, we want to study ASAT warning trends in software via the example of PMD as an ASAT and its usage in open source projects. We analyzed the commit history of 54 projects (with 112,266 commits in total), taking into account 193 PMD rules and 61 PMD releases. We investigate trends of ASAT warnings over up to 17 years for the selected study subjects regarding changes of warning types, short and long term impact of ASAT use, and changes in warning severities. We found that large global changes in ASAT warnings are mostly due to coding style changes regarding braces and naming conventions. We also found that, surprisingly, the influence of the presence of PMD in the build process of the project on warning removal trends for the number of warnings per lines of code is small and not statistically significant. Regardless, if we consider defect density as a proxy for external quality, we see a positive effect if PMD is present in the build configuration of our study subjects. Keywords Static code analysis · Quality evolution · Software metrics · Software quality
1 Introduction Automated static analysis tools (ASATs) support software developers with warnings and information regarding common coding mistakes, design anti-patterns like code smells (Fowler 1999), or code style violations. ASATs work directly on the source code or bytecode without executing the program. They are using abstract models of the source code, e.g., the Abstract Syntax Tree (AST) or the control flow graph to match the provided source Communicated by: Meiyappan Nagappan Alexander Trautsch
[email protected] 1
Institute of Computer Science, University of Goettingen, G¨ottingen, Germany
Empirical Software Engineering
code against a set of rules defined in the ASAT. If a part of the source code violates a predefined rule, a warning is generated. These rules can be customized by the project using the ASAT to fit their needs by removing rules deemed unnecessary. ASAT reports usually contain a type of warning, a short description, and the file and line number of the source code that triggered the warning. Developers can then inspect the line specified in the warning and decide if a change is necessary. The defects that can be found by static analysis include varying severities. Java String comparisons with “==” instead of using the equals() method, would compare the object reference instead of the object contents. The severi
Data Loading...
