Lase: Locating and applying systematic edits by learning from examples

Abstract

Adding features and fixing bugs often require systematic edits that make similar, but not identical, changes to many code locations. Finding all the relevant locations and making the correct edits is a tedious and error-prone process for developers. This paper addresses both problems using edit scripts learned from multiple examples. We design and implement a tool called LASE that (1) creates a context-aware edit script from two or more examples, and uses the script to (2) automatically identify edit locations and to (3) transform the code. We evaluate LASE on an oracle test suite of systematic edits from Eclipse JDT and SWT. LASE finds edit locations with 99% precision and 89% recall, and transforms them with 91% accuracy. We also evaluate LASE on 37 example systematic edits from other open source programs and find LASE is accurate and effective. Furthermore, we confirmed with developers that LASE found edit locations which they missed. Our novel algorithm that learns from multiple examples is critical to achieving high precision and recall; edit scripts created from only one example produce too many false positives, false negatives, or both. Our results indicate that LASE should help developers in automating systematic editing. Whereas most prior work either suggests edit locations or performs simple edits, LASE is the first to do both for nontrivial program edits.

The plastic surgery hypothesis

“…Overall, our results provide further evidence to support claims that it is promising to mine human commits for patterns, templates, and code fragments that can be reused to improve systems. This is a technique to which other authors have recently turned for automated program improvement [20,39] and for semi-automated improvement as decision support to software engineers [26,35], with promising results.…”

Automatic error elimination by horizontal code transfer across multiple applications

“…Because such techniques only provide reports that identify potential errors, and not inputs that demonstrate the actual existence of a suspected error, they are not directly relevant to CP. Example-Driven Program Edits: SYDIT [41] and LASE [42] are given an original and modified method and synthesize a transformation that, when applied to the original method, produces the modified method. The goal is to obtain a transformation that can be applied to other methods to achieve a similar semantic goal.…”

APIEvolutionMiner: Keeping API evolution under control

“…A possible alternative is to extract rules from code history. When analyzing source code history, information can be extracted by comparing two or more system versions [1], [2], [4], [11]. Some work mine changes only related to bug-fixes [3].…”