A report on a survey and study of static analysis users

Ayewah, Nathaniel; Pugh, William

doi:10.1145/1390817.1390819

Cited by 42 publications

(20 citation statements)

References 12 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Obviously the classifications made by users are subjective, but if users tend to give similar classifications to each issue, then we have more confidence in their decisions. In past lab studies, we have observed that independent reviewers generally are consistent about how they review issues [2,3].…”

Section: Checking For Consensusmentioning

confidence: 92%

The Google FindBugs fixit

Ayewah

Pugh

2010

Proceedings of the 19th International Symposium on Software Testing and Analysis

Self Cite

108

View full text Add to dashboard Cite

In May 2009, Google conducted a company wide FindBugs "fixit". Hundreds of engineers reviewed thousands of FindBugs warnings, and fixed or filed reports against many of them. In this paper, we discuss the lessons learned from this exercise, and analyze the resulting dataset, which contains data about how warnings in each bug pattern were classified. Significantly, we observed that even though most issues were flagged for fixing, few appeared to be causing any serious problems in production. This suggests that most interesting software quality problems were eventually found and fixed without FindBugs, but FindBugs could have found these problems early, when they are cheap to remediate. We compared this observation to bug trends observed in code snapshots from student projects.The full dataset from the Google fixit, with confidential details encrypted, will be published along with this paper.

show abstract

Section: Checking For Consensusmentioning

confidence: 92%

The Google FindBugs fixit

Ayewah

Pugh

2010

Proceedings of the 19th International Symposium on Software Testing and Analysis

Self Cite

108

View full text Add to dashboard Cite

show abstract

“…Ayewah et al [64,65] studied the usage of FindBugs where they saw that users are generally interested in fixing warnings from the tool, especially the high priority ones, but which types of warnings depends on the user's context. It is therefore deemed valuable to have configuration options for these different groups of users.…”

Section: Configurations Of Static Analysis Toolsmentioning

confidence: 99%

Why and how JavaScript developers use linters

Tomasdottir

Aniche

Deursen

2017

2017 32nd IEEE/ACM International Conference on Automated Software Engineering (ASE)

View full text Add to dashboard Cite

A linter is a type of static analysis tool that warns software developers about possible errors in code or violations to coding standards. By using such a tool, errors can be surfaced early in the development process when they are cheaper to fix, and code can be kept more readable and maintainable. For such a tool to be successful, it is important for its creators to understand the needs and challenges of developers when using a linter. Furthermore, it needs to be made clear to developers why using such a tool can be beneficial, along with how linters can be configured to identify appropriate and relevant issues for their projects.In this thesis, we examine developers' perceptions of linters to increase our knowledge on these tools for JavaScript, the most widely used programming language in the world today. More specifically, we study why and how developers use ESLint, the most popular JavaScript linter, along with the challenges that they face while using the tool. We collect data with three different methods where we first interview 15 experts on using linters, then analyze over 9,500 ESLint configuration files and finally survey more than 300 developers from the JavaScript community. The combined results from these analyses provide developers, tool makers and researchers with valuable knowledge and advice on using and developing a linter for JavaScript.

show abstract

“…This largely goes hand-in-hand with actionable messages: a message is only actionable if there is a clear and obvious reason why the message appeared at all. Prior research also has emphasized that programmers must develop trust for analysis tools [14], [17].…”

Section: ) Obvious Reasoningmentioning

confidence: 99%

Does bug prediction support human developers? Findings from a Google case study

Lewis

Lin

Sadowski

et al. 2013

2013 35th International Conference on Software Engineering (ICSE)

113

View full text Add to dashboard Cite

Abstract-While many bug prediction algorithms have been developed by academia, they're often only tested and verified in the lab using automated means. We do not have a strong idea about whether such algorithms are useful to guide human developers. We deployed a bug prediction algorithm across Google, and found no identifiable change in developer behavior. Using our experience, we provide several characteristics that bug prediction algorithms need to meet in order to be accepted by human developers and truly change how developers evaluate their code.

show abstract

A report on a survey and study of static analysis users

Cited by 42 publications

References 12 publications

The Google FindBugs fixit

The Google FindBugs fixit

Why and how JavaScript developers use linters

Does bug prediction support human developers? Findings from a Google case study

Contact Info

Product

Resources

About