2014 6th International Workshop on Empirical Software Engineering in Practice

What Kinds of Refactorings are Co-occurred?
An Analysis of Eclipse Usage Datasets
Tsubasa Saika1 , Eunjong Choi1 , Norihiro Yoshida2 , Akira Goto1 , Shusuke Haruna1 , Katsuro Inoue1
1

Graduate School of Information Science and Technology, Osaka University, Japan{t-saika, ejchoi, a-gotoh, haruna, inoue}@ist.osaka-u.ac.jp
2
Graduate School of Information Science, Nagoya University, Japan
yoshida@ertl.jp

Abstract—Refactoring is the process of changing the internal
structure of software without changing its external behavior. So
far, numerous tools have been proposed on that refactoring support. However, it is difﬁcult for existing refactoring support tools
to support consecutively co-occurred refactorings. To alleviate
this problem, a tool which supports consecutively co-occurred
refactorings is required. In order to develop a tool support offrequently co-occurred refactorings, this study investigated thefrequency of co-occurred refactorings by analyzing usage data of
Eclipse. As a result of investigation, it turns out that refactoring
pairs (Move, Rename), (Rename, Rename) and (Extract, Move)were more frequently occurred than other pairs. Furthermore, inorder to support co-occurred refactorings based on the results of
the investigation, this study investigated the detail of co-occurred
refactorings and devised suggestions for improving the automatedrefactoring features in Eclipse. In the investigation of refactoringpair (Move, Rename), we found that program elements weremoved and subsequently the names of those elements wererenamed. According to this ﬁnding, we suggest the need of atool for supporting this refactoring by recommending appropriate
rename for moved elements.

I.

different kinds of refactorings, a number of usage datasets of
IDE should be investigated to know what kinds of refactorings
frequently co-occurred [8].
In this study, we investigate the frequency of co-occurred
refactoring by analyzing usage data of Eclipse from the Usersand the Mylyn datasets (see Section II), and then discuss futureadvancement of the refactoring feature of Eclipse based on theinvestigation result.
The main contribution of this paper is as follows:•

We revealed that the refactoring pairs (Move,
Rename), (Rename, Rename) and (Extract,Move) were more frequently occurred than otherpairs.

•

We performed manual analysis of the instances ofabove refactoring pairs. As a result, in the caseof refactoring pair (Move, Rename), Rename isoccurred to change the names of program elementthat were moved previously. Also, in the case of
refactoring pair (Rename, Rename), Rename refactorings are performed together regardless of types oftargeted program elements in many cases. In the caseof refactoring pair (Extract Interface, Move),extracted interfaces are moved into other packages inmany cases.

•

Based on the result of manual analysis, we suggested
the directions for the improvement of the refactoring
feature of Eclipse. For the refactoring pair (Move,
Rename), recommending appropriate new name for
moved elements should be considered. Also, the feature of simultaneous renaming should be improved forthe refactoring pair (Rename, Rename).

I NTRODUCTION

Refactoring is the process of changing a software systemin such a way that it does not alter the external behavior [1][2]. Although refactoring is a promising way to improve themaintainability of software, manual refactoring is not only
time-consuming but also error-prone [3]. Nowadays, several
modern IDEs (e.g., Eclipse, IntelliJ IDEA) support many refactoring that rename, move, or split program elements including
methods, classes, and packages. The software engineeringcommunity also proposed tool supports for refactoring [4]–[6].
In order to improve refactoring tools, prior studies havebeen done on the usage instances of the existing refactoring tools [7]. These studies show that developers use thoserefactoring tools mostly for simple refactorings (e.g., Rename,
Extract Local Variable, Move), and often repeat thesame kinds of refactorings. This repetition phenomenon provides evidence that the existing tools force developers to
repeatedly select, initiate and conﬁgure refactoring dialogs, andimplies the need of a tool that allows developers to perform
those refactorings at one time. On the other hand, refactoring
tools also need to support seamless transition among different
kinds of refactorings that frequently co-occurred. However,existing tools basically force developers to perform thosekinds of refactorings individually. By supporting those cooccurred refactorings, software development efﬁciency shouldbe improved. In order to realize seamless transition among
978-1-4799-6666-0/14 $31.00 © 2014 IEEE
DOI 10.1109/IWESEP.2014.15

II.

A NALYZED DATASETS

To investigate refactoring tool usage, this study selected
two usage datasets of Eclipse named Users and Mylyn. They
are selected because they include usage logs of refactoring
features in Eclipse. Table I shows a summary of the datasets.
The ﬁrst dataset is called Users which contains the refactoring history of 41 developers from July 2005 to September
2005. It contains total 3494 refactoring instances that werecomprised of 22 types of refactoring.
The second dataset is called Mylyn which contains the
refactoring history of 8 developers from February 2006 to
31

TABLE I.
Name
Users
Mylyn

TABLE III.

S TATISTICS OF THE DATASETS# Refactoring
Instances
3494
4637

# Types ofRefactoring
22
19# Developers
41
8

PeriodJul. 2005-Sep. 2005
Feb. 2006-Aug. 2009

TABLE II.

R EFACTORINGS IN THE Users DATASET

Refactoring Type
RenameExtract Local Variable
Extract Method
Move
InlinePromote Local Variable
Extract Constant
Modify Parameters
Pull Up
Convert Local To Field
Convert Anonymous To Nested
Introduce Parameter
Extract Interface
Change Method Signature
Move Static Member
Convert Member Type to Top Level
Encapsulate Field
Use Supertype
Externalize Strings
Change Type
Generalize Type
Infer Type Arguments
Total# Instances
1992
449
305
180
174
95
59
40
36
29
29
25
24
16
12
8
8
6
4
1
1
1
3494

R EFACTORINGS IN THE Mylyn DATASET

Refactoring Type
RenameMove
Extract Method
Extract Local Variable
Extract ConstantMove Static Member
Change Method Signature
InlineConvert Member Type to Top Level
Infer Type Arguments
Extract Interface
Encapsulate Field
Convert Anonymous To Nested
Extract Superclass
Promote Local Variable
Pull Up
Push Down
Use Supertype
Introduce Parameter
Total

Proportion
57.0%
12.9%
8.7%
5.2%
5.0%
2.7%
1.7%
1.1%
1.0%
0.8%
0.8%
0.7%
0.7%
0.5%
0.3%
0.2%
0.2%
0.2%
0.1%
0.0%
0.0%
0.0%
100.0%# Instances
2401
691
305
254
245
235
191
110
44
30
29
29
23
16
15
14
3
1
1
4637

Proportion
51.8%
14.9%
6.6%
5.5%
5.3%
5.1%
4.1%
2.4%
0.9%
0.6%
0.6%
0.6%
0.5%
0.3%
0.3%
0.3%
0.1%
0.0%
0.0%
100.0%

plug-in for Eclipse. Developers in this dataset may not be experts of refactoring. However, we assume that they know muchabout refactoring features of Eclipse than general developers
because they develop Mylyn monitor tool.
We use database which is originally collected by Emerson
Murphy-Hill at el. [7]. This database contains details of eachrefactoring instance such as type, date and time, and affected
program elements. In addition to this, we also check Git
repository of Mylyn project for the detailed analysis.

August 2009. It contains total 4637 refactoring instances thatwere comprised of 19 types of refactoring.

Table III shows the number of instances of refactoring in
the Mylyn dataset and the proportion to the total. This table isalso sorted according to the numbers of refactoring instances.

The details of each dataset are described in the following
subsections.
A. Users Dataset

III.

Users dataset contains refactoring histories of the 41 developers who uses Eclipse for developing. It is originally collected
by Gail Murphy at el. [9]. Developers in this dataset work at
different organizations with various backgrounds. We expect
this dataset shows general tendency of software development
since the developers are not specialists of refactoring.

I NVESTIGATION S TEPThis section illustrates our investigation in order to devise
suggestions for developing tools that support frequently cooccurred refactorings. The investigation is comprised of two
steps. In the ﬁrst step, we investigated the number of instances for all combinations of co-occurred refactorings fromthe datasets. In the second step, we further investigated theinstances by manual analysis of the commit logs as well assource code.

The format of histories in this data is an XML ﬁle that iscreated separately for each commit by the Mylyn monitor tool.
This includes histories of conﬁguration changes of development environment, implementations of commands, editions ofsource codes, and other actions. For each refactoring recordedin this dataset, its types and when it was performed canbe found. However, the information about program elements
affected by the refactorings was unavailable in this dataset.

Step1. Investigating frequencies of co-occurred refactorings
In this step, we identiﬁed consecutively co-occurred refactorings based on time stamps which indicate when each refactoring was performed. Then, we investigated frequency for all
combinations of co-occurred refactorings found in the datasets.
In this step, if refactorings were occurred within 90 seconds,
we deﬁned them as co-occurred refactorings. We set up 90
seconds as threshold of determining co-occurred refactorings
based on the our preliminary experiment.

Table II shows the number of instances of refactoring
performed in the Users dataset and the proportion to the total indescending order to the numbers of instances. As shown in thistable, the most frequently occurred refactoring in Users dataset
is Rename which changes a name of a program element andits references. It is commonly known as the most popular typeof refactoring.

In the preliminary experiment, we investigated repeatedly
performed different kinds of refactoring in relation to timeinterval. We found that it seems to be too short to complete
the refactoring in less than 60 seconds and also longer timeinterval is likely to include falsely refactorings. We also foundthat types of refactorings appeared within 60, 90, and 120
seconds are similar to each other. Therefore, we selected 90

B. Mylyn Dataset
Mylyn dataset contains refactoring histories of the developers who maintain the Mylyn monitor tool, the task management32

seconds as the time-interval because it is long enough to extract
about 60 presents of all refactorings consecutively performedin the data sets.

TABLE IV.

Refactoring Type
Refactoring 1
Refactoring 2
Extract Method
RenameExtract Local Variable
RenameExtract Local Variable
Extract Method
RenameExtract Method
RenameMove
Extract Method
InlineExtract Local Variable
InlineInlineExtract Local Variable
Extract Local Variable
Promote Local Variable
Move
RenameHowever, there is a possibility the refactorings consecutively performed may not be refactorings which the developer
performed as one task. To alleviate this problem, we further
investigated relationship between co-occurred refactorings byanalyzing their details in the next step.
Step2. Investigating detailed work of frequently cooccurred refactoring
In this step, we investigated the detailed works of frequently co-occurred refactorings. We analyzed how program
elements, the targets of co-occurred refactorings, were modiﬁed. The goal of this investigation is to identify how developers
changed program with the combinations of refactorings and to
consider support for performing those refactorings. However,this investigation was carried out only for the Mylyn dataset
because information such as the target of refactoring has notbeen included in the Users dataset as mentioned in Section
II-A. We analyzed targets of co-occurred refactorings byinvestigating 10 instances of detailed refactoring histories foreach combination of the top 10 high frequencies. Moreover, we
examined the targets of co-occurred refactorings are whether
the same or whether or not related. A combination of cooccurred refactorings is determined to be related when theirtargets have similar name or belong to the same class or
package.
IV.

F REQUENTLY C O - OCCURRED R EFACTORINGS IN THE
Users DATASETTABLE V.

# Instances
35
22
19
17
15
14
14
14
12
12

F REQUENTLY C O - OCCURRED R EFACTORINGS IN THE Mylyn
DATASET

Refactoring Type
Refactoring 1
Refactoring 2
Move
RenameRenameMove
Extract Interface
Move
Extract ConstantRenameExtract ConstantMove
Extract Method
RenameExtract Method
Extract Local Variable
Extract Local Variable
RenameRenameChange Method Signature
InlineRename# Instances
88
62
12
11
10
9
6
6
5
5

TABLE VI.
F REQUENTLY C O - OCCURRED R EFACTORINGS IN THE
Mylyn DATASET IN THE C ASE W HERE TARGETS OF R EFACTORING AREC LASSIFIED FOR Rename AND Move
Refactoring Type
Refactoring 1
Refactoring 2
Rename Type
Move
Move
Rename Type
Rename Field
Rename Method
Rename Method
Rename Field
Move
Rename Package
Rename Type
Rename Method
Rename Method
Rename Type
Rename Type
Rename Field
Rename Field
Rename Type
Extract Interface
Move

R ESULTS

This section shows results of our investigation. Section IVA explains the results of the investigation on frequencies of cooccurred refactorings. Then, Section IV-B explains the resultsof the investigation on the detailed work of frequently cooccurred refactorings.
A. Frequently Co-occurred Refactorings
This section describes the results of Step1 which investigates frequencies of co-occurred refactorings. Table IV and Vshows the investigation result of the Users dataset and Mylyn
dataset respectively. In both tables, “Refactoring Type” column
shows types of co-occurred refactorings. “# Instances” column
represents the number of refactoring instances of each combinations. Note that these tables are sorted in descending orderof the number of refactoring instances and only show the top
ten frequently occurred pairs in terms of frequency, because weare only interested in more frequently co-occurred refactorings.
As shown in both tables, in most cases, refactorings were
subsequently occurred twice. In fact, the numbers of instancesof any combinations which are consisted of three or morerefactorings are less than ﬁve times. These two tables show
similar combinations of co-occurred refactorings. That is, mostcombinations of co-occurred refactorings contain at least oneof Rename, Move, and Extract. These refactoring types arealso shown as the most frequently occurred refactoring types
in Table II and III.

# Instances
30
28
26
22
19
16
16
13
13
12

Rename Field, Rename Method, and Rename Local
Variable. Table VI shows the result of this classiﬁcation.
This table also shows combinations which are occurred morethan 10 times. The result of this classiﬁcation shows that
Rename refactorings are performed together regardless oftypes of modiﬁed program elements in many cases.
B. Detailed Co-occurred Refactoring Instances
In this section, we explain the results of Step 2. whichinvestigated the detailed works for frequently co-occurred
refactorings of the Mylyn dataset. We invetigated the details ofwork of the top 10 most frequently co-occurred refactorings.
We checked targets of refactoring and classiﬁed them into three
types (same, related, and others). In some cases, targets of cooccurred refactorings are the same program element. In othercases, targets are determined as related program elements ifthey have similar name or belong to the same package or class.
In the rest cases, we could not identify the relationship between
targets.

In terms of Mylyn dataset, this dataset includes
information about targets of all refactoring instances.
Therefore, we classiﬁed Rename refactorings into several types: Rename Type(Class), Rename Package,

Table VII shows the result of investigation on the detailed
work for frequently co-occurred refactoring. The order of33

A S UMMARY OF I NVESTIGATION INTO D ETAIL W ORKS OF F REQUENTLY C O - OCCURRED R EFACTORINGS IN THE Mylyn DATASETTABLE VII.

Refactoring Type
Refactoring 1
Refactoring 2
Move
Rename Type
Rename Field
Rename Method
Rename Type
Rename Method
Move
Rename Package
Rename Type
Rename Field
Move Static Member
Rename Field
Extract Interface
Move
Rename Local Variable
Rename Field
Move
Move Static Member
Move
Rename Field# Performed
58
48
32
29
26
15
14
12
12
12

# Investigated
10
10
10
10
10
10
10
10
10
10

# Same
4
0
0
1
0
6
7
0
0
0

# Related
1
5
4
7
3
0
1
6
2
0

Packageporg.eclipse.mylyn.internal.tasks.ui.properties

org eclipseorg.eclipse.mylyn.tasks.ui

org.eclipse.mylyn.internal.tasks.ui.views

Moves the classto other Package

TaskElementLabelProvider.java

Move
M
ProjectPreferences
LinkProvider.java

Field

ProjectPreferences
LinkProvider.java

ProjectProperties
ope
LinkProvider.java

Renames the class name

L… Variable
Local
compositeImages
compositeImag…
}

Fig. 1. An Instance of Detailed Work for (Move,Rename) from the Mylyn
Dataseteach combination is ignored. Same as shown in the Table
VI in Section IV-A, Rename and Move refactorings areclassiﬁed according to their applied types. The numbers of
performed refactoring, investigated refactoring, same targets,and related targets are shown in Table VII. More than half of
all investigated refactoring-pairs are same or related.

wideImages
RenameFig. 2. An Instance of Detailed Work for (Rename,Rename) from the Mylyn
Datasetorg.eclipse.mylyn.tasks.ui to package named
org.eclipse.mylyn.internal.tasks.ui.properties.
Moreover,
its
class
name
is
changedfrom
ProjectPreferencesLinkProvider
toProjectPropertiesLinkProvider
using
Rename Type refactoring. Its new nameincludes a word properties (shown in red
font) come from its new package named
org.eclipse.mylyn.internal.tasks.ui.properties.

Hereinafter, we summarize an overview of the detailed
works for the most frequently co-occurred refactorings: (Move,
Rename), (Rename, Rename), and (Extract, Move).
1)

wideImages

TaskElementLabelProvider(…){
T

RenameClass

RenamecompositeImages
ccompo(Move, Rename)
About refactoring pair of Move and Rename, itturned out that Rename are occurred to change thenames of program element that were moved previously. In the case where targets of Move and Rename
refactorings were the same program element, program
elements such as packages, classes, and ﬁelds wererenamed immediately after they were moved. In thecase where targets of Move and Rename refactorings
had similar name or belong to the same package
or class, the names of classes and packages werechanged after program elements such as classes ﬁelds,
and methods were moved into it.
Figure 1 depicts an instance of detailed workof Move and Rename Type refactorings
simultaneously performed in Mylyn project.
This instance is found from a commit recordedin the Git repository of Mylyn project1 . In
this ﬁgure, a class named ProjectPreferencesLinkProvider was moved from package named

2)

1 http://git.eclipse.org/c/mylyn/org.eclipse.mylyn.tasks.git/
tree/org.eclipse.mylyn.tasks.ui/src/org/eclipse/mylyn/internal/tasks/ui/properties/ProjectPropertiesLinkProvider.java?id=
a4907cc0d72cdc9e6eb7c1e62234edd01214b072(Rename, Rename)
About refactoring pair of Rename and Rename, itturned out that Rename refactorings are performed
together regardless of types of targeted program elements in many cases. In addition, those program
elements tend to have similar names and some relationship. For example, a local variable of constructor,
setter method, or getter method and a relating ﬁeld
variable are often renamed together.
Figure 2 shows an instance where Rename Field,
Rename Local Variable refactorings wereused together in Mylyn project. This instance is foundfrom a commit recorded in the Git repository of
Mylyn project2 In this ﬁgure, a ﬁeld variable named
compositeImages is renamed to wideImages

2 http://git.eclipse.org/c/mylyn/org.eclipse.mylyn.tasks.
git/diff/org.eclipse.mylyn.tasks.ui/src/org/eclipse/mylyn/internal/tasks/ui/views/TaskElementLabelProvider.java?id=
62f11037485847c03b5e9f7c309ac1f25ee9a242

34

using Rename Field refactoring. Moreover, a
local variable also named compositeImages issimilarly renamed to wideImages using Rename
Local Variable refactoring.
3)

this combination. But if the location to create newJava ﬁle can be selected in the dialog of Extract
Interface refactoring, it is unnecessary to perform
Move refactoring separately.
Some limitations exist in this study because we investigatedthe data sets in the period of 2005 to 2009. Refactoring featuresin version of Eclipse at the time would be different from thoseof the latest version. Therefore, we need to investigate a recent
data set to examine how developers have changed the way of
refactoring. However, the usability problems revealed in thisstudy still exists in the current version of Eclipse.

(Extract Interface, Move)
About refactoring pair of Extract Interface
and Move, it turned out that extracted interfaces are
moved into other packages in many cases.
V.

D ISCUSSION

As a result of the investigation, the most frequently cooccurred refactoring is revealed. Based on the investigation
results, this section explains our suggestions for improving
refactoring features of Eclipse as follows.
1)

VI.

Murphy et al. reported on usage data collected from 41
Java software developers using Eclipse, providing a glimpse
into their work habits [9]. According to their report, themost common refactoring commands were Rename, Move,and Extract. Murphy-Hill and Black observed 11 programmers perform a number of Extract Method refactorings,
and then revealed room for two types of improvements toExtract Method refactoring tools [10]. First, to preventa large number of errors in the ﬁrst place, programmers
need support in making a valid selection. Second, to help
programmers successfully recover from violated preconditions,programmers need expressive, distinguishable, and understandable feedback that conveys the meaning of precondition violations. Based on the revealed room, they presented three toolsthat help programmers avoid selection errors and understandrefactoring precondition violations. Also, Murphy-Hill et al.
revealed that programmers often repeat the same types ofrefactorings [7]. According to their investigation, about 40% of
refactorings performed using tool occur in batches. Also, theyfound that about 90% of conﬁguration defaults in refactoring
tools are not changed when programmers use the tools. We investigated repeatedly performed different kinds of refactorings
based on the usage instances of the existing refactroing tools.

(Move, Rename)Based on the results of the investigation, a refactoring
tool needs to supports developers to consecutively
perform Rename refactoring after Move refactoring.
Currently, Eclipse does not provide interaction
between Move and Rename refactorings. Therefore,
developers need to perform Move and Rename
refactoring separately and conﬁguration dialog
appear twice even though developers often do not
conﬁgure refactoring tools [7]. For supporting thiscombinations of refactorings, making a new menu
which simultaneously performs Move and Rename
refactorings in Eclipse can be useful. If the name ofthe program element can be changed in the dialog
of Move refactoring, it is unnecessary to perform
Rename refactoring separately. Recommending
appropriate new name for moved elements is also
can be useful for supporting this combinations.

2)(Rename, Rename)

Vakilian et al. collected a set of interaction data from about
1268 hours of programming using our minimally intrusive datacollectors [11]. Their quantitative data shows that programmers
prefer lightweight methods of invoking refactorings, usually
perform small changes using the refactoring tool, proceed with
an automated refactoring. They found that programmers use
predictable automated refactorings even if they have rare bugs
or change the behavior of the program. Vakilian and Johnson
proposed an approach to discovering the usability problem on
the refactoring feature of Eclipse by collecting alternate refactoring paths (i.e., a sequence of user interactions that contains
cancellations, reported messages, or repeated invocations of
the refactoring tool) [12]. Their approach revealed 15 usability
problems, 13 of which were previously unknown. We would
like to investigate whether or not our suggestion in Section
V is able to reduce the usability problem on the refactoring
feature of Eclipse.

For supporting these refactorings, tool should support
rename several program elements regardless of theirtypes can be useful for supporting this refactoring
pair. In the current speciﬁcation of refactorings ofEclipse, for only the Rename refactoring intended
for class, elements with the similar names can be
automatically renamed together. However, there isno such support for Rename refactoring intended
for other types of program elements such as ﬁelds or
methods. Therefore, it is necessary to support themin the same way.
3)

R ELATED W ORK(Extract Interface, Move)
Based on the investigation results, a refactoring
tool needs to supports developers to consecutively perform Move refactoring after Extract
Interface refactoring. In the current speciﬁcationof refactorings of Eclipse, Move refactoring of ajava ﬁle can be carried out easily with drag-and-dropfrom the Package Explorer. Therefore, it is consideredthat sufﬁcient support is being made already for

Kim et al. presented a ﬁeld study of refactoring beneﬁts
and challenges at Microsoft [13]. Their survey found that therefactoring deﬁnition in practice is not conﬁned to a rigorousdeﬁnition of semantics-preserving code transformations. We
need to investigate refactoring instances in industrial projects
as well as in OSS projects. Also, Kim et al studied API-level35refactorings and bug ﬁxes in three large open source projects,
totaling 26523 revisions of evolution [14]. One of their ﬁndings
is that an increase is conﬁrmed in the number of bug ﬁxes afterAPI-level refactorings. We hope to investigate whether or notco-occurred refactorings affect bug ﬁxes.

dataset. This work was supported by JSPS KAKENHI Grant
Numbers 25220003 and 26730036.
R EFERENCES[1]

Several studies have been done on seamless support for
refactoring [5], [6], [15], [16]. BeneFactor [6], GhostFactor[16] and WitchDoctor [5] monitor code modiﬁcation on the
ﬂy, and then dynamically utilize the monitoring result for
refactoring support. They detect the beginning of refactoring,and pro-actively recommend a series of code transformation tocomplete the refactoring. Lee et al. proposed Drag-and-Drop
Refactoring, which allows programmers to directly manipulate
program elements (e.g., variables, expressions, statements,
methods) in IDE [15]. We suggested seamless support for cooccurred refactorings in Section V.

[2]
[3]

[4]

[5]

[6]

VII.

S UMMARY[7]

To develop a tool that supports different kinds of cooccurred refactorings, this study preliminary investigates repeatedly performed different kinds of refactorings based on
the developers’ refactoring tool usage.

[8]

[9]

In summary, the most co-occurred refactorings are (Move,
Rename), (Rename, Rename), and (Extract, Move).
Moreover, based on the investigation of the detailed works forthese co-occurred refactorings, we suggested several improvements of refactoring feature in Eclipse for supporting them.
In order to support the refactoring pair (Move, Rename),the refactoring feature needs to support developers to simultaneously perform this combination. For the refactoring pair
(Rename, Rename), the tool must be able to perform multiple
Rename refactorings together regardless of types of theirtargeted program elements.

[10]

[11]

[12]
[13]
[14]

As future work, it is necessary to clarify beneﬁts ofsupporting co-occurred refactorings. We expect that supporting
co-occurred refactorings certainly improves software development efﬁciency. However, it has not been investigated yet
for the effect on occurrence of bugs. Also, we are goingto analyze additional software systems to achive generalityof our ﬁndings. In addition, we are interested in comparing
batched refactorings between legacy software projects including a number of bad smells and well-maintained software
project. We expect that such legacy project tends to cause
higher number of batched refactorings compared to wellmaintained projects. Especially, we would like to investigate
whether or not combined bad smells [17] and/or the amount ofcode clones [18] increase the number of batched refactorings.
Also, industrial ﬁled study [13] on batched refactorings is aninteresting challenge. Finally, we would like to develop a tool
for supporting refactoring according to the ﬁndings from theinvestigations.
VIII.

[15]

[16]
[17]

[18]

ACKNOWLEDGMENT

We express our great thanks to Dr. Gail C. Murphy, Dr. Mik
Kersten and Dr. Leah Findlater at the University of British
Columbia for providing the Users dataset, and Dr. Emerson
Murphy-Hill at North Carolina State University, Dr. Chris
Parnin at the Georgia Institute of Technology and Dr. Andrew
P. Black at Portland State University for providing the Mylyn

36

M. Fowler, Refactoring:Improving the Design of Existing Code. Addison Wesley, 1999.
W. F. Opdyke, “Refactoring object-oriented frameworks,” Ph.D. dissertation, University of Illinois at Urbana-Champaign, 1992.
G. Bavota, B. De Carluccio, A. De Lucia, M. Di Penta, R. Oliveto, andO. Strollo, “When does a refactoring induce bugs? an empirical study,”
in Proc. of SCAM, 2012, pp. 104–113.
R. Tairas and J. Gray, “Increasing clone maintenance support byunifying clone detection and refactoring activities,” Inf. Softw. Technol.,vol. 54, no. 12, pp. 1297–1307, 2012.
S. R. Foster, W. G. Griswold, and S. Lerner, “WitchDoctor: IDE support
for real-time auto-completion of refactorings,” in Proc. of ICSE, 2012,
pp. 222–232.
X. Ge, Q. L. DuBose, and E. R. Murphy-Hill, “Reconciling manual andautomatic refactoring,” in Proc. of ICSE, 2012, pp. 211–221.
E. Murphy-Hill, C. Parnin, and A. P. Black, “How we refactor, and how
we know it,” IEEE Trans. Softw. Eng., vol. 38, no. 1, pp. 5–18, 2012.
M. Vakilian, N. Chen, R. Z. Moghaddam, S. Negara, and R. E. Johnson,“A compositional paradigm of automating refactorings,” in Proc. of
ECOOP, 2013, pp. 527–551.
G. C. Murphy, M. Kersten, and L. Findlater, “How are java softwaredevelopers using the Eclipse IDE?” IEEE Softw., vol. 23, no. 4, pp.
76–83, 2014.
E. Murphy-Hill and A. P. Black, “Breaking the barriers to successful
refactoring: observations and tools for extract method,” in Proc. of ICSE,
2008, pp. 421–430.
M. Vakilian, N. Chen, S. Negara, B. A. Rajkumar, B. P. Bailey, andR. E. Johnson, “Use, disuse, and misuse of automated refactorings,” inProc. of ICSE, 2012, pp. 233–243.
M. Vakilian and R. E. Johnson, “Alternate refactoring paths reveal
usability problems,” in Proc. of ICSE, 2014, pp. 1106–1116.
M. Kim, T. Zimmermann, and N. Nagappan, “A ﬁeld study of refactoring challenges and beneﬁts,” in Proc. of FSE, 2012, pp. 1–11.
M. Kim, D. Cai, and S. Kim, “An empirical investigation into the roleof api-level refactorings during software evolution,” in Proc. of ICSE,
2011, pp. 151–160.
Y. Y. Lee, N. Chen, and R. E. Johnson, “Drag-and-drop refactoring:
Intuitive and efﬁcient program transformation,” in Proc. of ICSE, 2013,
pp. 23–32.
X. Ge and E. Murphy-Hill, “Manual refactoring changes with automatedrefactoring validation,” in Proc. of ICSE, 2014, pp. 1095–1105.
A. Yamashita and L. Moonen, “Exploring the impact of inter-smell
relations on software maintainability: an empirical study,” in Proc. of
ICSE, 2013, pp. 682–691.
T. Kamiya, S. Kusumoto, and K. Inoue, “CCFinder: a multilinguistic
token-based code clone detection system for large scale source code,”IEEE Trans. Softw. Eng., vol. 28, no. 7, pp. 654–670, 2002.