Refactorings without names
Proceedings of the 27th IEEE/ACM International Conference on Automated Software Engineering - ASE 2012
As with design patterns before, the naming and cataloguing of refactorings has contributed significantly to the recognition of the discipline. However, in practice concrete refactoring needs may deviate from what has been distilled as a named refactoring, and mapping these needs to a series of such refactorings -if at all possible -can be difficult. To address this, we propose a framework of specifying refactorings in an ad hoc fashion, and demonstrate its feasibility by presenting an
... tion. Evaluation is done by simulating application through a user on a set of given sample programs. Results suggest that our proposal of ad hoc refactoring is, for the investigated scenarios at least, viable. PROLOGUE "There is no substitute for the compiler and a good test suite for checking to see if a refactoring accidentally changes behavior of a system ..." [anonymous reviewer, ASE 2012] "Program testing can be used to show the presence of bugs, but never to show their absence!" [EWD268] We think of refactoring tools as metaprograms that play in the same league as editors, debuggers, and version control systems. Few programmers would tolerate if one of these tools silently changed the behaviour of their programs, and we consider a refactoring tool which does so as flawed. With our work, we strive for a level of correctness beyond what "a good test suite" can ascertain.