Continuous code quality: are we (really) doing that?

Vassallo, Carmine; Palomba, Fabio; Bacchelli, Alberto; Gall, Harald C.

doi:10.1145/3238147.3240729

Cited by 36 publications

(17 citation statements)

References 29 publications

(39 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Recent work investigated the limits of ASAT tools in industrial (e.g., Google [84]) and open source context [90], and proposed solutions to reduce the number of alarms they generate [67,38] or summarize the ASAT-related information contained in build logs [94]. Moreover, Mahmood et al [65] compare static analysis tools for Java and C/C++ source code and explore their pros and cons.…”

Section: Related Workmentioning

confidence: 99%

How developers engage with static analysis tools in different contexts

et al. 2019

Self Cite

View full text Add to dashboard Cite

Automatic static analysis tools (ASATs) are instruments that support code quality assessment by automatically detecting defects and design issues. Despite their popularity, they are characterized by (i) a high false positive rate and (ii) the low comprehensibility of the generated warnings. However, no prior studies have investigated the usage of ASATs in different development contexts (e.g., code reviews, regular development), nor how open source projects integrate ASATs into their workflows. These perspectives are paramount to improve the prioritization of the identified warnings. To shed light on the actual ASATs usage practices, in this paper we first survey 56 developers (66% from industry and 34% from open source projects) and interview 11 industrial experts leveraging ASATs in their workflow with the aim of understanding how they use ASATs in different contexts. Furthermore, to investigate how ASATs are being used in the workflows of open source projects, we manually inspect the contribution guidelines of 176 open-source systems and extract the ASATs' configuration and build files from their corresponding GitHub repositories. Our study highlights that (i) 71% of developers do pay attention to different warning categories depending on the development context; (ii) 63% of our respondents rely on specific factors (e.g., team policies and composition) when prioritizing warnings to fix during their programming; and (iii) 66% of the projects define how to use specific ASATs, but only 37% enforce their usage for new contributions. The perceived relevance of ASATs varies between different projects and domains, which is a sign that ASATs use is still not a common practice. In conclusion, this study confirms previous findings on the unwillingness of developers to configure ASATs and it emphasizes the necessity to improve existing strategies for the selection and prioritization of ASATs warnings that are shown to developers.

show abstract

Section: Related Workmentioning

confidence: 99%

How developers engage with static analysis tools in different contexts

et al. 2019

Self Cite

View full text Add to dashboard Cite

show abstract

“…They argue one of the main reasons is that developers who use static analyzers do not configure them to break builds because they do not want to be forced to cope with the warnings. Vassallo et al [39] also report that developers do not perform continuous code quality checks over time, rather they do it at the end of development sprints. This finding confirm the usefulness of SORALD in helping developers handle static warnings as early as possible.…”

Section: Static Code Analysis Usagementioning

confidence: 99%

Sorald: Automatic Patch Suggestions for SonarQube Static Analysis Violations

Etemadi,

Harrand,

Larsen

et al. 2021

Preprint

View full text Add to dashboard Cite

Previous work has shown that early resolution of issues detected by static code analyzers can prevent major cost later on. However, developers often ignore such issues for two main reasons. First, many issues should be interpreted to determine if they correspond to actual flaws in the program. Second, static analyzers often do not present the issues in a way that makes it apparent how to fix them. To address these problems, we present SORALD: a novel system that adopts a set of predefined metaprogramming templates to transform the abstract syntax trees of programs to suggest fixes for static issues. Thus, the burden on the developer is reduced from both interpreting and fixing static issues, to inspecting and approving solutions for them. SORALD fixes violations of 10 rules from SONARQUBE, one of the most widely used static analyzers for Java. We also implement an effective mechanism to integrate SORALD into development workflows based on pull requests. We evaluate SORALD on a dataset of 161 popular repositories on GITHUB. Our analysis shows the effectiveness of SORALD as it fixes 94% (1,153/1,223) of the violations that it attempts to fix. Overall, our experiments show it is possible to automatically fix violations of static analysis rules produced by the state-of-the-art static analyzer SONARQUBE.

show abstract

“…The use of static bug finders for software defect detection is a common practice for developers during software development and has been studied by many researchers [14,24,41,46,63]. There were studies investigating the adoption of static bug finders within continuous integration pipelines [43,54,62]. Other studies focused on how these warnings are actually acted, and fixed [22,36,52].…”

Section: Related Workmentioning

confidence: 99%

Context-aware in-process crowdworker recommendation

Wang

Yang

Wang

et al. 2020

Proceedings of the ACM/IEEE 42nd International Conference on Software Engineering

View full text Add to dashboard Cite

Static bug finders have been widely-adopted by developers to find bugs in real-world software projects. They leverage predefined heuristic static analysis rules to scan source code or binary code of a software project, and report violations to these rules as warnings to be verified. However, the advantages of static bug finders are overshadowed by such issues as uncovered obvious bugs, false positives, etc. To improve these tools, many techniques have been proposed to filter out false positives reported or design new static analysis rules. Nevertheless, the under-performance of bug finders can also be caused by the incorrectness of current rules contained in the static bug finders, which is not explored yet. In this work, we propose a differential testing approach to detect bugs in the rules of four widely-used static bug finders, i.e., SonarQube, PMD, SpotBugs, and ErrorProne, and conduct a qualitative study about the bugs found. To retrieve paired rules across static bug finders for differential testing, we design a heuristic-based rule mapping method which combines the similarity in rules' description and the overlap in warning information reported by the tools. The experiment on 2,728 open source projects reveals 46 bugs in the static bug finders, among which 24 are fixed or confirmed and the left are awaiting confirmation. We also summarize 13 bug patterns in the static analysis rules based on their context and root causes, which can serve as the checklist for designing and implementing other rules and/or in other tools. This study indicates that the commonly-used static bug finders are not as reliable as they might have been envisaged. It not only demonstrates the effectiveness of our approach, but also highlights the need to continue improving the reliability of the static bug finders.

show abstract

Continuous code quality: are we (really) doing that?

Cited by 36 publications

References 29 publications

How developers engage with static analysis tools in different contexts

How developers engage with static analysis tools in different contexts

Sorald: Automatic Patch Suggestions for SonarQube Static Analysis Violations

Context-aware in-process crowdworker recommendation

Contact Info

Product

Resources

About