Static analysis is an important part of today's quality assurance process. It can be performed manually, by means of code reviews, or automatically, by automated static analysis tools (ASATs). However, there is still much unknown about the state of static analysis. This includes
...
Static analysis is an important part of today's quality assurance process. It can be performed manually, by means of code reviews, or automatically, by automated static analysis tools (ASATs). However, there is still much unknown about the state of static analysis. This includes hard data on how prevalent static analysis is among projects. And while there have been studies on how projects use code reviews, current research has not investigated how developers configure the ASATs that they use and how these configurations evolve. In this thesis, we answer these questions by means of a large scale analysis of open source software. We found that both code reviews and ASATs are common, but not ubiquitous. Many projects do not perform code reviews for the changes of core developers and do not enforce a strict use of ASATs. Regarding the use of ASATs, developers both use and avoid maintainability defects to a greater extent than functional defects. Most configurations of developers deviate from the default and hardly contain custom rules. However, there are few default rules that are changed by a significant percentage of developers. Finally, most configuration files never change. And if they do, the changes are small, occur over the lifetime of the project, and are not triggered by ASAT version updates.