Learning Quick Fixes from Code Repositories

Abstract

Code analyzers such as Error Prone and FindBugs detect code patterns symptomatic of bugs, performance issues, or bad style. These tools express patterns as quick fixes that detect and rewrite unwanted code. However, it is difficult to come up with new quick fixes and decide which ones are useful and frequently appear in real code. We propose to rely on the collective wisdom of programmers and learn quick fixes from revision histories in software repositories. We present REVISAR, a tool for discovering common Java edit patterns in code repositories. Given code repositories and their revision histories, REVISAR (i) identifies code edits from revisions and (ii) clusters edits into sets that can be described using an edit pattern. The designers of code analyzers can then inspect the patterns and add the corresponding quick fixes to their tools. We ran REVISAR on nine popular GitHub projects, and it discovered 89 useful edit patterns that appeared in 3 or more projects. Moreover, 64% of the discovered patterns did not appear in existing tools. We then conducted a survey with 164 programmers from 124 projects and found that programmers significantly preferred eight out of the nine of the discovered patterns. Finally, we submitted 16 pull requests applying our patterns to 9 projects and, at the time of the writing, programmers accepted 6 (60%) of them. The results of this work aid toolsmiths in discovering quick fixes and making informed decisions about which quick fixes to prioritize based on patterns programmers actually apply in practice.

Mining Idioms in the Wild

“…2 At first blush, this may look like a pattern matching or clone detection problem, where a code fragment that is a candidate for refactoring might be a clone of code that was refactored in the past to introduce an API call. Another candidate approach might aim to extract generalizable code transformations from a small set of specific examples of transformations [4,10,21,22,26,31,32].…”

“…In recent years, we have seen an emerging trend of tools and techniques that synthesize program transformations from examples of code edits [4,10,21,22,26,31,32]. The synthesized transformation should satisfy the given examples while producing correct edits on unseen inputs.…”

“…Moreover, the former only accepts one example and synthesizes the transformation using the most general generalization, whereas the latter accepts multiple examples and synthesizes the transformation using the most specific generalization. This approach is also the approach taken by Revisar [32] and Getafix [4]. ReFazer [10,31] learns a set of transformations consistent with the examples and uses a set of heuristics to rank the transformations in order of likelihood to be correct.…”

Anti-unification of Unordered Goals

“…The algorithms described in all of these works can be used to compute what we will call ⊑-common generalizations below in the present paper. Although none of these works develop a general (non-equational) taxonomy allowing to extend the results beyond that simple setting, nor discusses variable-or injectivity-based variants of antiunification operators, their usages do point out other interesting (and recent) applications of anti-unification when focused on unordered goals, namely detection of recursion schemes in functional programs (as explained in [2]) and techniques for learning bugfixes from software code repositories (an example being [27]).…”

Learning to Represent Edits

“…Rolim et al (2017) use such clusters to synthesize small programs that perform the edit. The approach is based on Rolim et al (2018) extract manually designed syntactic features from code and cluster over multiple changes to find repeatable edit rules. Similarly, Paletov et al (2018) extract syntactic features specifically targeting edits in cryptography API protocols.…”