Scalable, example-based refactorings with refaster

Wasserman, Louis R.

doi:10.1145/2541348.2541355

Cited by 27 publications

(10 citation statements)

References 4 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…It is used by developer teams that ensure persistent information from protocol buffers in their serialized form but is annoying for teams that do not store data in this form. Another example is an analyzer that suggests using Guava 37 or Java 7 idioms that do not make sense for projects that cannot use these libraries or language features;…”

Section: Even In a Mature Codebase With Full Test Coverage And A Rigomentioning

confidence: 99%

Lessons from building static analysis tools at Google

et al. 2018

View full text Add to dashboard Cite

For a static analysis project to succeed, developers must feel they benefit from and enjoy using it. BY CAITLIN SADOWSKI, EDWARD AFTANDILIAN, ALEX EAGLE, LIAM MILLER-CUSHON, AND CIERA JASPAN Not integrated. The tool is not integrated into the developer's workflow or takes too long to run; Not actionable. The warnings are not actionable; Not trustworthy. Users do not trust the results due to, say, false positives; Not manifest in practice. The reported bug is theoretically possible, but the problem does not actually manifest in practice; SOFTWARE BUGS COST developers and software companies a great deal of time and money. For example, in 2014, a bug in a widely used SSL implementation ("goto fail") caused it to accept invalid SSL certificates, 36 and a bug related to date formatting caused a large-scale Twitter outage. 23 Such bugs are often statically detectable and are, in fact, obvious upon reading the code or documentation yet still make it into production software. Previous work has reported on experience applying bug-detection tools to production software. 6,3,7,29 Although there are many such success stories for developers using static analysis tools, there are also reasons engineers do not always use static analysis tools or ignore their warnings, 6,7,26,30 including: key insights ˽ Static analysis authors should focus on the developer and listen to their feedback. ˽ Careful developer workflow integration is key for static analysis tool adoption. ˽ Static analysis tools can scale by crowdsourcing analysis development.

show abstract

Section: Even In a Mature Codebase With Full Test Coverage And A Rigomentioning

confidence: 99%

Lessons from building static analysis tools at Google

et al. 2018

View full text Add to dashboard Cite

show abstract

“…Many such edits have already been performed in the past by the same developers in a different codebase location, or by other developers in a different program/codebase. For instance, to apply an API update, a developer needs to locate all references to the old API and consistently replace them with the new API [1], [2]. As another example, in programming courses student submissions that exhibit the same fault often need similar fixes.…”

Section: Introductionmentioning

confidence: 99%

Learning Syntactic Program Transformations from Examples

Rolim¹,

Soares

D’Antoni

et al. 2017

2017 IEEE/ACM 39th International Conference on Software Engineering (ICSE)

192

148

View full text Add to dashboard Cite

Abstract-Integrated Development Environments (IDEs), such as Visual Studio, automate common transformations, such as Rename and Extract Method refactorings. However, extending these catalogs of transformations is complex and time-consuming. A similar phenomenon appears in intelligent tutoring systems where instructors have to write cumbersome code transformations that describe "common faults" to fix similar student submissions to programming assignments.In this paper, we present REFAZER, a technique for automatically generating program transformations. REFAZER builds on the observation that code edits performed by developers can be used as input-output examples for learning program transformations. Example edits may share the same structure but involve different variables and subexpressions, which must be generalized in a transformation at the right level of abstraction. To learn transformations, REFAZER leverages state-of-the-art programming-by-example methodology using the following key components: (a) a novel domain-specific language (DSL) for describing program transformations, (b) domain-specific deductive algorithms for efficiently synthesizing transformations in the DSL, and (c) functions for ranking the synthesized transformations.We instantiate and evaluate REFAZER in two domains. First, given examples of code edits used by students to fix incorrect programming assignment submissions, we learn program transformations that can fix other students' submissions with similar faults. In our evaluation conducted on 4 programming tasks performed by 720 students, our technique helped to fix incorrect submissions for 87% of the students. In the second domain, we use repetitive code edits applied by developers to the same project to synthesize a program transformation that applies these edits to other locations in the code. In our evaluation conducted on 59 scenarios of repetitive edits taken from 3 large C# open-source projects, REFAZER learns the intended program transformation in 83% of the cases and using only 2.8 examples on average.

show abstract

“…As far as we know, these transformation frameworks for Java do not consider type safety either, and there is no guarantee that the transformation does not introduce compilation errors. Refaster [28] uses compilable before-and-after examples of Java code to specify a Java refactoring. Similarly to our work, this work also mainly focuses on solving the method replacement which is useful in real API migration.…”

Section: Related Workmentioning

confidence: 99%

Swin

Wang

Xiong

et al. 2015

Proceedings of the 2015 Workshop on Partial Evaluation and Program Manipulation

View full text Add to dashboard Cite

Java program adaptation between different APIs is a common task in software development. When an old API is upgraded to an incompatible new version, or when we want to migrate an application from one platform to another platform, we need to adapt programs between different APIs. Although different program transformation tools have been developed to automate the program adaptation task, no tool ensures type safety in transforming Java programs: given a transformation program and any well-typed Java program, the transformed result is still well-typed. As a matter of fact, it is often observed that a dedicated adaptation tool turns a working application into a set of incompatible programs.We address this problem by providing a type-safe transformation language, SWIN, for Java program adaptation between different APIs. SWIN is based on Twinning, a modern transformation language for Java programs. SWIN enhances Twinning with more flexible transformation rules, formal semantics, and, most importantly, full type-safe guarantee. We formally prove the type safety of SWIN on Featherweight Java, a known minimal formal core of Java. Our experience with three case studies shows that SWIN is as expressive as Twinning in specifying useful program transformations in the case studies while guaranteeing the type safety of the transformations.

show abstract

Scalable, example-based refactorings with refaster

Cited by 27 publications

References 4 publications

Lessons from building static analysis tools at Google

Lessons from building static analysis tools at Google

Learning Syntactic Program Transformations from Examples

Swin

Contact Info

Product

Resources

About