Active Support for Clone Refactoring: A Perspective
Norihiro Yoshida

Eunjong Choi

Nara Institute of Science and Technology, Japanyoshida@is.naist.jp

Osaka University, Japan{ejchoi, inoue}@ist.osaka-u.ac.jp

Abstractfrom the perspective of dynamic support based on online
analysis of code modification.

Clone refactoring (merging duplicate code) is a promisingsolution to improve the maintainability of source code. In
this position paper, we discuss directions towards the advancement of clone refactoring, and show a perspective ofactive support based on online analysis of code modification
on an editor of IDE.

2. Related work
Several approaches have been proposed on the identification and the categorization of clone refactoring opportunities
in source code. Balazinska et al. [1] proposed an approachfor supporting clone refactoring by categorizing code clones
based on the differences of them. Baxter et al. [2] have developed a clone detection tool CloneDR based on AST similarity. CloneDR derives only syntactically-complete clones
that can be easily refactored. Hotta et al. [12] focused onForm Template Method refactoring pattern [7], and proposeda specialized approach to identifying its opportunities. For
the prioritization of clone refactoring opportunities, Higo etal. [11] and Choi et al. [5] proposed metric-based approaches
respectively. Also, search-based approaches have been proposed for scheduling clone refactoring based on its benefit
and effort [3, 17, 24].
A few approaches have been proposed on automatic codetransformation for clone refactoring. Tairas and Gray [21]have developed an Eclipse plugin CEDAR that realizes automatic code transformation for clone refactoring using therefactoring feature of Eclipse. For Form Template Methodrefactoring, Juillerat and Hirsbrunner [14] proposed an automatic code transformation approach based on AST comparison.
An Eclipse plug-in JSync [18] will be invoked by explicit
requests or SVN commits of developers, and then report potential inconsistent modifications to clones. JSync is one of
the notable tools that support clone maintenance dynamically. However, it is unresponsive to code modification on
an editor of IDE, so still differs from the online analysis ofcode modification.
To our knowledge, there is no tool that supports clone
refactoring based on the online analysis of code modification. In next section, we discuss challenges in the tool development for clone refactoring from the perspective of dynamic support based on the online analysis of code modification.

Categories and Subject Descriptors D.1.5 [ProgrammingTechniques]: Object-oriented Programming
Keywords Refactoring, Code clone, IDE

1.

Katsuro Inoue

Introduction

Clone refactoring is a series of the code transformation tomerge similar parts of source code into a single program unit
(e.g., Java method, C++ function). It is aimed at improving
the maintainability of the source code.
Several tools for non-clone refactoring monitor codemodification on the fly, and then dynamically utilize themonitoring result for refactoring support. For example,BeneFactor [8] and WitchDoctor [6] detect the beginningof refactoring, and proactively recommend a series of codetransformation to complete the refactoring. On the other
hand, in the case of clone refactoring, dynamic support basedon the online analysis of code modification is very limited
despite the complexity of its process. In clone refactoring, adeveloper detects all of clones that are similar to each other,and then determine whether those clones should be refactored according to maintainability impact and the difficultyof the refactoring. Finally, he/she merges those clones into asingle module if possible and appropriate.
In this position paper, we argue research objectives anddirections towards the advancement of clone refactoring

Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor profit or commercial advantage and that copies bear this notice and the full citationon the first page. Copyrights for components of this work owned by others than ACM
must be honored. Abstracting with credit is permitted. To copy otherwise, or republish,
to post on servers or to redistribute to lists, requires prior specific permission and/or afee. Request permissions from permissions@acm.org.
WRT ’13, October 27, 2013, Indianapolis, Indiana, USA.
c 2013 ACM 978-1-4503-2604-9/13/10. . . $15.00.
Copyright 
http://dx.doi.org/10.1145/2541348.2541352

13ĚŝƚŽƌƉůƵŐͲŝŶŽĚĞŵŽĚŝĨŝĐĂƚŝŽŶƐ^ĞĐƚŝŽŶϯ͘ϭĐƚŝǀĞĐůŽŶĞĚĞƚĞĐƚŝŽŶZĞĨĂĐƚŽƌŝŶŐĞƚĞĐƚŝŽŶZĞĨĂĐƚŽƌŝŶŐĚĞƚĞĐƚŝŽŶƌĞƐƵůƚ^ĞĐƚŝŽŶϯ͘ϯ WƌŽĂĐƚŝǀĞƌĞĨĂĐƚŽƌŝŶŐĐĂŶĚŝĚĂƚĞĚĞƚĞĐƚŝŽŶůŽŶĞĚĞƚĞĐƚŝŽŶƌĞƐƵůƚ^ĞĐƚŝŽŶϯ͘ϮZĞĨĂĐƚŽƌŝŶŐĐĂŶĚŝĚĂƚĞƐĞůĞĐƚŝŽŶZĞĨĂĐƚŽƌŝŶŐĐĂŶĚŝĚĂƚĞĞǀĞůŽƉĞƌFigure 1. An overview of the research directions that we argue

3.

Research Directions

tools have been developed on incremental clone detectionthat identifies newly-changed clones by comparing current
and previous revisions [9, 13], the challenges still remains
on when and how to catch code modification, how to reflect
it to incremental clone detection implemented in IDE.
Another challenge is the development of a near real timeclone detection technique that can be invoked by modification in a source code editor, and then can finish the detection
at by the timing of next modification. Also, the detection
technique is required to cover various types of clones. This isbased on the practice that clones are frequently merged even
if not only variations exist in identifiers, literals, and types
but also modifications are made such as changed, added orremoved statements [4, 7, 20].
The output of this step is passed to the steps described insection 3.2 and 3.3 respectively.

Figure 1 illustrates an overview of the research directions
that we argue in this section. In section 3.1, we argue approaches that perform clone detection incrementally whena developer modifies source code on an editor plug-in of
an IDE (e.g., Eclipse). And then, section 3.2 presents approaches that fiter out clones that should be detected fromthe output of section 3.1. Finally, in section 3.3, we argue
approaches to detecting refactoring based on the analysis ofcode modifications on a code editor, and then recommending
to refactor clones of the refactored code at one time.
3.1

Active clone detection

According to our experience in the application of clone related tools into industry, developers are interested in only
newly-appeared clones because of the following reasons[23]:3.2• Previously-existing clones are often manually verified

Refactoring Candidate Selection

Several studies pointed out that clones are not always refactoring candidates [10, 15, 16] even in the case of newlyappeared one [23]. For precise refactoring candidate selection, the following two types of clones should be filtered out
from the output of the clone detection described in the section 3.1 [11, 23].
At first, syntactically incomplete clones should be not
be detected [11, 23]. According to the experience in applying clone detection to industrial software development [23],and recognized as harmless for the maintainability of thesource code.
• Editing previously-existing clones often leads reperfor-

mance of large-scale test (e.g., integration/system test)
that consumes much time.
Therefore, it is necessary to develop a tool that performs
clone detection incrementally when a developer modifies
source code on an editor plug-in of an IDE. Although several

14

clones include whole parts of loop or branch statements wereconsidered as ones that should be merged. Meanwhile, developers rarely recognize clones include only parts of loopor branch statements as ones should be merged because it isdifficult to merge syntactically incomplete clones.
Also, according to the industrial experience [23], in thecase of clones that were newly-appeared by adding newcode, developers frequently recognize them as ones shouldbe merged. On the other hand, clones are sometimes accidentally created by only the replacement or the deletion ofstatements. In other words, even if no line is added to a codefragment, it sometimes becomes a code clone together withother code fragments when one (or greater than one) character is changed in it. In such case, developers mostly decideto leave those clones as it is.
One of the challenges is discovering further heuristics foreliminating clones that should not be detected. Also, anotherchallenge is that how to visualize the refactoring candidates
derived in this step. A straightforward visualization is listingthem in a view of IDE, and updating the list once a developer
modifies source code.
3.3ĞǀĞůŽƉĞƌůŽŶĞůŽŶĞdŽŽůůŽŶĞdŽŽůĚĞƚĞĐƚƐƚŚĞďĞŐŝŶŶŝŶŐŽĨƚŚĞƌĞĨĂĐƚŽƌŝŶŐ

(a) Refactoring detectionEĞǁŵĞƚŚŽĚůŽŶĞdŽŽůůŽŶĞdŚĞŶƚŽŽůŝĚĞŶƚŝĨŝĞƐƚŚĞĐŽƌƌĞƐƉŽŶĚŝŶŐĐůŽŶĞƐ͘

Proactive Refactoring Candidate Detection(b) Identification of the corresponding clones

When a developer applies a well-defined refactoring transformation to a code fragment, it implies that he/she should
consider whether or not to refactor the clones of the codefragment. For example, when a developer extracts a codefragment as a method, he/she should consider whether or notto extract the clones of the code fragment, and then merge
them into the same method at one time.
Fortunately, much research has been done on the detection of refactoring between previous and current revisions[19, 22]. Those refactoring detection techniques are promising to identify the behaviors of a developer who refactor acode fragment.
Figure 2 illustrates an example of proactive refactoring
candidate detection using refactoring detection technique. At
first, once a developer extracts a clone as a new method, thetool for proactive refactoring candidate detection identifies
the refactoring (Figure 2(a)) , and then discovers the clones
corresponding to the refactored clone (Figure 2(b)) according to the output of the clone detection described in section
3.1. Finally, the tool recommends him to merge those clones
into the new method (Figure 2(c)). In Figure 2(c), a browndashed arrow means that a clone is replaced by a call of thenew method.
UI for recommending refactoring candidates is a challenge as well as the step in section 3.2.

4.

EĞǁŵĞƚŚŽĚ

KŶĐĞŚĞĞǆƚƌĂĐƚƐĂĐůŽŶĞĂƐĂŶĞǁŵĞƚŚŽĚ͙ĞǀĞůŽƉĞƌ

EĞǁŵĞƚŚŽĚ
ůŽŶĞ

ůŽŶĞ

dŽŽů
dŽŽůƌĞĐŽŵŵĞŶĚƐŚŝŵƚŽŵĞƌŐĞƚŚŽƐĞĐůŽŶĞƐŝŶƚŽƚŚĞŶĞǁŵĞƚŚŽĚ͘(c) Recommendation of refactoring candidates

Figure 2. Proactive Refactoring Candidate Detection
spective of dynamic support based on online analysis of code
modification.

Acknowledgments
We express our great thanks to Dr. Zhenchang Xing atNanyang Technological University for helpful comments.
This work was supported by JSPS KAKENHI Grant Numbers 21240002 and 25220003.

SummaryReferences

In this position paper, we reviewed studies related with clone
refactoring, and argued research objectives and directions
towards the advancement of clone refactoring from the per-[1] M. Balazinska, E. Merlo, M. Dagenais, B. Laguë, and K. Kontogiannis. Measuring clone based reengineering opportunities. In Proc. of METRICS ’99, pages 292–303, 1999.

15[2] I. D. Baxter, A. Yahin, L. Moura, M. S. Anna, and L. Bier.
Clone detection using abstract syntax trees. In Proc. of ICSM
’98, pages 368–377, 1998.

[14] N. Juillerat and B. Hirsbrunner. Toward an implementationof the ”form template method” refactoring. In SCAM, pages
81–90, 2007.

[3] S. Bouktif, G. Antoniol, E. Merlo, and M. Neteler. A novel
approach to optimize clone refactoring activity. In GECCO,
pages 1885–1892, 2006.

[15] C. Kapser and M. W. Godfrey. “Cloning considered harmful”
considered harmful: patterns of cloning in software. Empirical
Software Engineering, 13(6):645–692, 2008.

[4] E. Choi, N. Yoshida, and K. Inoue. What kind of and howclones are refactored?: A case study of three OSS projects.
In Proceedings of the Fifth Workshop on Refactoring Tools,
WRT ’12, pages 1–7, 2012.

[16] M. Kim, V. Sazawal, D. Notkin, and G. C. Murphy. An empirical study of code clone genealogies. In ESEC/SIGSOFT
FSE, pages 187–196, 2005.

[5] E. Choi, N. Yoshida, T. Ishio, K. Inoue, and T. Sano. Extracting code clones for refactoring using combinations of clonemetrics. In IWSC, pages 7–13, 2011.

[17] S. Lee, G. Bae, H. S. Chae, D.-H. Bae, and Y. R. Kwon.
Automated scheduling for clone-based refactoring using acompetent GA. Software: Practice and Experience, 41(5),2011.

[6] S. R. Foster, W. G. Griswold, and S. Lerne. WitchDoctor: IDE
Support for Real-Time Auto-Completion of Refactorings. In
Proc. of ICSE, pages 222–232, 2012.

[18] H. A. Nguyen, T. T. Nguyen, N. H. Pham, J. M. Al-Kofahi,and T. N. Nguyen. Clone management for evolving software.
IEEE Trans. Softw. Eng., 38(5):1008–1026, 2012.

[7] M. Fowler. Refactoring: improving the design of existingcode. Addison Wesley, 1999.

[19] K. Prete, N. Rachatasumrit, N. Sudan, and M. Kim. Templatebased reconstruction of complex refactorings. In Proc. ofICSM, 2010.

[8] X. Ge, Q. L. DuBose, and E. Murphy-Hill. Reconciling
manual and automatic refactoring. In Proc. of ICSE, pages
211–221, 2012.

[20] C. K. Roy, J. R. Cordy, and R. Koschke. Comparison andevaluation of code clone detection techniques and tools: Aqualitative approach. Sci. Comput. Program., 74(7):470–495,2009.

[9] N. Göde and R. Koschke. Frequency and risks of changes toclones. In Proc. of ICSE, pages 311–320, 2011.

[21] R. Tairas and J. Gray. Increasing clone maintenance support
by unifying clone detection and refactoring activities. Information & Software Technology, 54(12):1297–1307, 2012.

[10] Y. Higo, T. Kamiya, S. Kusumoto, and K. Inoue. Method andimplementation for investigating code clones in a softwaresystem. Information & Software Technology, 49(9-10):985–998, 2007.

[22] Z. Xing and E. Stroulia. Refactoring detection based onumldiff change-facts queries. In Proc. of WCRE, pages 263–274, 2006.

[11] Y. Higo, S. Kusumoto, and K. Inoue. A metric-based approach to identifying refactoring opportunities for merging
code clones in a Java software system. Journal of Software
Maintenance and Evolution, 20(6):435–461, 2008.

[23] Y. Yamanaka, E. Choi, N. Yoshida, K. Inoue, and T. Sano.
Applying clone change notification system into an industrial
development process. In ICPC, pages 199–206, 2013.

[12] K. Hotta, Y. Higo, and S. Kusumoto. Identifying, tailoring,and suggesting form template method refactoring opportunities with program dependence graph. In CSMR, pages 53–62,
2012.

[24] M. F. Zibran and C. K. Roy. A constraint programming
approach to conflict-aware optimal scheduling of prioritizedcode clone refactoring. In SCAM, pages 105–114, 2011.

[13] B. Hummel, E. Juergens, L. Heinemann, and M. Conradt.
Index-based code clone detection: incremental, distributed,scalable. In Proc. of ICSM, pages 1–9, 2010.

16