Does Automated Refactoring Obviate Systematic Editing? – Miryung Kim

Sometimes you need to make similar, but not identical edits to source code. A lot of work has already been done on this, for example example-based program transformations.

But is this a good idea? By automating systematic editing, you are increasing code duplication, because you make it easier to maintain code clones. An alternative would be, of course, to remove code clones, instead of doing a systematic edit.

The research question then is: does systematic editing indeed encourage code duplication? This paper aims to combine the best of both world!

The idea of this paper is to exploit systematic edits for code clone removal.

First, Rase takes systematic edits as input:

2015-05-21 11.36.43

Then a refactoring plan is created and executed, which is challenging as not all edits are exactly the same. There can be differences in names, types, changes to state etc.

For this, Miryung used 5 refactorings known to remove code clones:

Parameterize type, form template method, add parameter, introduce return object and introduce exit label.

An example:

In case of type variations, first create generalized types:

2015-05-21 11.40.06

In case there is a code block to extract, but uses multiple variables as output, you can introduce a new return type:

2015-05-21 11.42.01

So, by using the 5 refactorings, many different types of clone removal are possible.


On an existing test suite that Miryung used for a previous paper, consisting of 56 similarly changed method pairs and 30 similarly changed method groups.

Then she asked the question: Is clone removal refactoring feasible? On the set, rase could refactor 20 out of 30 method groups and 30 out of 56 method pairs.

So, what happened in the other cases? Sometimes, methods are unmovable, like super() Sometimes, groups are edited together, but there was no common code to extract.

The paper is here:

This post was visited 94 times.