Refactoring is not (yet) about transformation

  • Authors:
  • Torbjörn Ekman;Max Schäfer;Mathieu Verbaere

  • Affiliations:
  • University of Oxford, UK;University of Oxford, UK;University of Oxford, UK

  • Venue:
  • Proceedings of the 2nd Workshop on Refactoring Tools
  • Year:
  • 2008

Quantified Score

Hi-index 0.00

Visualization

Abstract

In order to ensure correctness, refactorings have to check extensive preconditions before performing the transformation. These preconditions usually involve subtle analyses of the program to be refactored, and as long as there is no good support for implementing them, refactoring is not about transformation, but about analysis. In most cases, these refactoring analyses are very similar to analyses implemented in a compiler and require the same level of detail to ensure behaviour preservation. We therefore propose to implement a refactoring engine on top of a compiler to leverage existing infrastructure, and complement it with refactoring-specific functionality. Many simple refactorings appear as building blocks in more complex refactorings. We have implemented two such building blocks that are widely useful: The first one allows to move symbolic names from one place in the program to another while preserving binding structure; it frees the developer from having to worry about issues like name clashes and accidental overriding. The second building block encapsulates data flow and control flow analyses, enabling the developer to specify precise conditions for validity of a transformation in terms of concepts like dominance and liveness. Based on these approaches, we have implemented a refactoring engine as part of a larger effort to generate IDEs from declarative language specifications using the JastAdd metacompiler tools. The described building blocks were successfully used as a foundation for other refactorings such as Rename, Extract Method, and Encapsulate Field.