社団法人 電子情報通信学会
THE INSTITUTE OF ELECTRONICS,
INFORMATION AND COMMUNICATION ENGINEERS

信学技報
TECHNICAL REPORT OF IEICE.

Finding Code Clones for Refactoring with Clone Metrics :A Case Study of Open Source Software
Eunjong CHOI† , Norihiro YOSHIDA†† , Takashi ISHIO† , Katsuro INOUE† , and Tateki SANO†††† Graduate School of Information Science and Technology, Osaka University
1–5 Yamadaoka, Suita-shi, Osaka, 565–0871 Japan†† Graduate School of Information Science, Nara Institute of Science and Technology
8916–5 Takayama-cho, Ikoma-shi, Nara, 630–0192 Japan††† Software Process Innovation and Standardization Division, NEC Corporation
5–7–1 Shiba, Minato-ku, Tokyo, 108–8001 Japan
E-mail: †{ejchoi,ishio,inoue}@ist.osaka-u.ac.jp, ††yoshida@is.naist.jp, †††t-sano@cp.jp.nec.com
Abstract A code clone is a code fragment that has identical or similar code fragments to it in the source code.
Code clone has been regarded as one of the factors that makes software maintenance more diﬃcult. Therefore, torefactor code clones into one method is promising way to reduce maintenance cost in the future. In our previous
study, we proposed a method to extract code clones for refactoring using clone metrics. We had conducted anempirical study on Java application developed by NEC Corporation. It turned out that our proposed method iseﬀective to extract refactoring candidate code clones. In this paper, we show the result of applying our proposed
method into open source software systems.
Key words code clone, refactoring, open source software

1. Introduction

clones for refactoring using clone metrics. We showed theusefulness of our proposed method with a survey to a de-

Code clone is similar or identical code fragments in source

veloper in NEC Corporation. According to the feedback, it

code. The presence of code clones has been regarded as in-turned out that our proposed method using combined clone

dication of low maintainability of software because if a bug

metrics is eﬀective method to extract code clones for refac-

is found in a code clone, the other code clone have to be

toring.

checked for defect detection.
Refactoring [5] is the process of changing a software system

However, due to the time limitation, we conducted on asingle system in previous study.

Therefore, although we

in such a way that it does not alter the external behavior

could validate our method in previous study, our methodof the code yet improves its internal structure. Refactoring

may not generalize to other software systems.

code clones (e.g., merge code clones into a single method in

In this study, we apply our proposed method to open

Java program) is an eﬀective way to reduce code clones in asource software and discuss its results. The rest of this paper

software system.

is organized as follows: We ﬁrst expalin the background of

However, all code clones detected by a code clone detec-

our study in Section 2 and then describe a case study and its

tion tool are not appropriate for refactoring. For example,

results in Section 3. Section 4 discusses threats to validity.

language-dependent code clones [6] (i.e. code clones that in-

Section 5 surveys related work, and Section 6 concludes ourdispensably exist in a source code due to the speciﬁcations ofpaper.

used program language) are clearly inappropriate for refactoring. Although, numerous techniques and tools have been
proposed for code clone detection [8], [11], only little has been
known about which detected code clones are appropriate forrefactoring and how to extract code clones for refactoring.
Our previous study [4] proposed method to extract code

2. BackgroundIn this section, we explain about clone metrics and ourprevious method based on them.
2. 1 Clone Metrics
Our research group have developed and proposed a token—1—

based code clone detection tool CCFinder [11] and a codethese clone sets include a lot of language-dependent code

clone analysis environment Gemini [13] which visualizes theclones.

code clone information from CCFinder. Gemini supports

2. 3 Combinations of Clone Metrics

clone metrics LEN(S), POP(S) and RNR(S) [6], [13]. EachOur research group have suggested code clones for refac-of them characterize a clone set (i.e. an equivalent of code•

LEN(S) − The average number of token sequence ofthat are extracted using just high single clone metric are inappropriate for refactoring due to the weakness described incode clones in a clone set S.
•

toring to industrial software developers.
However, according to their opinion, many of code clones

clones) S:

POP(S) − The number of code clones in a clone set

Section 2. 2. In order to improve the weakness of singlemetric-based extraction, we proposed a method based on

S.
•

RNR(S) − The ratio of non-repeated token sequence“combination of clone metrics”. The followings are the details about the conducted case study in previous study forof code clone in a clone set S.
The deﬁnition of RNR(S) metric is described in Equation (1). If clone set S includes n code clones, c1 , c2 . . . , cn ,LOSwhole (fi ) is the Length Of the whole token Sequence ofcode clone ci . LOSnon−repeated (fi ) is the Length Of non-validating the our proposed method that using combined
clone metrics.
2. 3. 1 Target Clone Sets
The target of the case study was a Java software developedby NEC corporation. It is 110KLOC across 296 ﬁles. From

repeated token Sequence of code clone ci , then,736 clone sets that are detected by CCFinder, we selected∑

62 clone sets using a single clone metric value, and combinedn

RN R(S) =i=1

LOSnon−repeated (ci )n∑clone metrics values. We used 30 tokens as the minimum
× 100

(1)

LOSwhole (ci )i=1

2. 2 Features of Clone Sets Whose Each Clone
Metric is Higher

length of token sequence of a code clone to CCFinder.
The following are the details of subject clone sets:
•
high.
•

Gemini characterizes code clones using clone metrics. Our

high.

research group has analyzed clone sets in numerous software•systems for several proposes (e.g., refactoring, defect-check)high.

using Gemini. The followings are the characteristics of clone•

sets extracted by each clone metric [6].
•Clone sets whose LEN(S) is higher than others −Clone sets whose LEN(S) is higher than other clone setsmeans that each code clone in a clone set S consists of longer
token sequences than others clone sets. According to ourobservation, many of them include many consecutive if (orif-else) blocks that involve similar but diﬀerent conditional
expressions.
•

Clone sets whose RNR(S) is higher than others −SLEN − Clone sets whose LEN(S) value are top 10
SRN R − Clone sets whose RNR(S) value are top 10
SP OP − Clone sets whose POP(S) value are top 10
SLEN ·RN R − 15 clone sets whose LEN(S) and RNR(S)values are high rank in the top 15.
•

SLEN ·P OP − 7 clone sets whose LEN(S) and POP(S)values are high rank in the top 15.
•

SRN R·P OP − 18 clone sets whose RNR(S) and POP(S)values are high rank in the top 15.
•

SLEN ·RN R·P OP − 1 clone set whose LEN(S), RNR(S)and POP(S) values are high rank in the top 15.
2. 3. 2 Results
We conducted a case study according to the following

Clone sets whose RNR(S) is higher than other clone sets

steps:

means that each code clone in a clone set S consists of more

（ 1 ） Selected clone sets (details about these clone sets

non-repeated code. According to our observation, because

are described in Section 2. 3. 1) from CCFinder’s output us-

clone metric RNR(S) distinguishes only “non-repeated” to-ing clone metrics in Gemini.

ken sequences from “repeated” token sequences of code（ 2 ） Conduct a survey about these clone sets and got

clones, many of them do not organize a single semantic unit

feedback from a developer. The developer is a project man-(i.e., many instructions forming a single functionality)

ager with 10 years of development experiences with Java.

•

Clone sets whose POP(S) is higher than others −（ 3 ） Analyze the result of conducted survey.

Clone sets whose POP(S) is higher than other clone sets

We use Precision to analyses results of the survey. It canmeans that code clones in a clone set S appear more fre-be used to investigate the question “How many clone setsquently in the system. According to our observation, thosewere accepted as refactorable clone sets by a developer?”clone sets include many small size code clones. Moreover,Equation (2) describes Precision. Let SAll represent all clone—2—

Table 1 Precisions in the survey conducted in previous study
Clone Sets

#Selected Clone Sets #Refactoring Precision

SLEN

10

7

0.70

SRN R

10

4

0.40

SP OP

10

3

0.30

SLEN ·RN R

15

13

0.87

SLEN ·P OP

7

6

0.86

SRN R·P OP

18

14

0.78

SLEN ·RN R·P OP

1

1

1.00

Table 2 Results of clone sets detected by a single clone metric, and combined metrics inthe survey
Filtering Method#Selected Clone Sets #Refactoring Precision

Single Clone Metric

30

14

0.47

Combined Clone Metrics

41

34

0.83

sets that are selected by each method, SARC represents clone

setting in previous study. The followings are the details ofsets accepted as refactorable clone sets by a developer.

each subject system.

P recision =|SARC |
|SAll |•
(2)

Tables 1 and 2 describe the result of the survey. In Tables
1 and 2, column Clone Sets shows name of target clone sets.
#Selected Clone Sets and #Refactoring show the numberof selected clones from CCFinder‘s output and the number ofclone sets that selected as refactorable clone sets in a survey
respectively.
As shown in the column “Precision” in Table 1, precisionsof SRN R , SP OP are smaller than 0.50. This means thatthose clone sets were accepted by a developer as inappropriate clone sets for refactoring.
However, precisions of SLEN , SLEN ·RN R , SLEN ·P OP ,SRN R·P OP , and SLEN ·RN R·P OP are more than 0.70. Thismeans that they were accepted by a developer as appropriate clone sets for refactoring. It is clear that all clone
sets that are extracted using combined clone metrics values(SLEN ·RN R , SLEN ·P OP , SRN R·P OP , and SLEN ·RN R·P OP )are more than 0.70 (They are shown in bold in column “Precision” in Table 1) are accepted as refactorable clone sets.
As shown in Table 2, Precision of clone sets that are extracted using combined clone metrics values are higher thanclone sets than using each single clone metric. Therefore, we
found code clones that extracted using combined clone metrics is more frequently accepted as refactorable clone sets
than using each single clone metric.

3. Case Study of Open Source Software
3. 1 Target Systems
In this study, we use two open source Java projects:
Apache Ant [2] and JBoss [1], as our target systems. We use
code clone detection tool, CCFinder and set 30 tokens as theminimum token length of a code clone because of its use andApache Ant − It is 198KLOC across 778 ﬁles. weselected 87 clone sets from 998 clone sets detected by
CCFinder.
•JBoss − It is 633KLOC across 3, 344 ﬁles. we selected

299 clone sets from 730 clone sets detected by CCFinder.
3. 2 Result
Table 3 shows the precisions of clone sets in each softwaresystem. The precisions are little diﬀerent from the previous study. The precisions of both SRN R , both SLEN ·RN R ,SLEN ·P OP in Apache Ant, SRN R·P OP , and SLEN ·RN R·P OP
in JBoss are more than 0.50 (They are shown in bold in column “Precision” in Table 3). The followings are our analysis
on the results.
•

SLEN (The precisions are 0.00 and 0.20 in Apache Ant

and JBoss respectively) − Code clones in those clone setsconsist many consecutive if (or if-else) blocks. Consecutive if(or if-else) blocks are diﬃcult to perform refactoring, generally. However, in previous study, just 2 types of parameters
are included in consecutive if (or if-else) blocks. Therefore, adeveloper selected many clone sets whose LEN(S) value are
top 10 high as refactorable clone sets. On the contrary, due
to various types of parameters are included in consecutive if(or if-else) blocks, it is inappropriate for refactoring of clone
sets in both Apache Ant and JBoss.
•SRN R (The precisions are 0.70 and 0.80 in Apache Ant

and JBoss respectively) − The size of many code clones inthose clone sets are short. Several clone sets in Apache Ant
and JBoss include insuﬃcient scale code clones to organize
semantic units..
•

SP OP (The precisions are 0.00 and 0.00 in Apache

Ant and JBoss respectively) − Code clones in clone sets
whose POP(S) are higher than other clone sets appear more
frequently in the system. Many of them in both Apache—3—Table 3 Results of each target system
Clone Sets
SLEN
SRN R
SP OP
SLEN ·RN R
SLEN ·P OP
SRN R·P OP
SLEN ·RN R·P OP

Target System #Selected Clone Sets #Refactoring Precision
Apache Ant

10

0

0.00

JBoss

10

2

0.20

Apache Ant

10

7

0.70

JBoss

10

8

0.80

Apache Ant

10

0

0.00

JBoss

10

0

0.00

Apache Ant

8

6

0.75

JBoss

63

37

0.59

Apache Ant

18

10

0.56

JBoss

104

3

0.03

Apache Ant

34

16

0.47

JBoss

129

32

0.25

Apache Ant

-

-

-

JBoss

2

2

1.00

Ant and JBoss appear frequently in the system because theysoftware(e.g., C/C++, Python). In order to improve theare language-dependent code clones and language-dependent

generality of our research, we need to investigate the useful-code clones are not appropriate refactoring.

ness of our method for source code written in without Java.

•SLEN ·RN R (The precisions are 0.75 and 0.59 in Apache

Ant and JBoss respectively) − Due to various parameter

5. Related Worktypes between code clones in clone sets in both Apache Ant

Jiang et al. [9] and Kapser et al. [12] pointed out that code

and JBoss, several of them could not be merged into a single

clone detection tools using parameterized matching detected

program unit.

a lot of false positives. Jiang et al. [9] used textual ﬁltering•

SLEN ·P OP (The precisions are 0.56 and 0.03 in Apachetechniques to remove false positives from CCFinder’s output.

Ant and JBoss respectively) − Several of thoses clone sets in-

They removed code clones whose textual similarity falls be-clude many language-dependent code clones in both Apache

low a certain threshold. Kapser et al. [12] proposed the fol-

Ant and JBoss. Therefore, many of them are inappropriate

lowing techniques to remove false positives from the output

for refactoring.

of their token-based clone detection tool.

•

SRN R·P OP (The precisions are 0.47 and 0.25 in Apache•

Identiﬁer names outside functions (e.g., Java methods,

Ant and JBoss respectively) − Several of thoses clone sets

C functions) are not parameterized. For example, declara-

do not consist of a single functionality in both Apache Anttions of ﬁeld variables in Java programs and external vari-and Jboss. Even though they include many instructions, in-ables in C programs are often duplicated but most of themstructions do not consist of a single functionality.

are false positives.

•

SLEN ·RN R·P OP (The precisions are 0.00 and 1.00 in

Apache Ant and JBoss respectively) − Those clone sets areappropriate for refactoring compared to the other combination of clone metrics.

4. Threats to Validity•

Simple method calls are matched only if Levenshtein

Disitance of those method names is small.
•

Logical structures (e.g., switch statements, if (or if-else) blocks) are matched if 50% of tokens in these structures
are identical.
There is the possibility to make our method more eﬀective

Due to the limited time and eﬀort, we only evaluate pre-by applying the ﬁltering techniques proposed by Jiang et al.

cision of our method. We believe that precision is a goodand Kapser et al. as the preprocessor or the postprocessor

enough criterion for validating our method.

of our method.

Moreover, because we use only 3 clone metrics in our stud-

CCFinderX [10] developed by Kamiya provides the metricies, it may not good enough to reveal the all characteristic of

TKS(S) that means the number of token types in code clones

appropriate code clones for refactoring. We are planning tobelonging clone set S. The metric TKS is eﬀective to remove

use other clone metrics and source code metrics (e.g., com-

clone sets not in need of developer’s investigation (e.g., con-plexity metrics).

secutive variable declarations) because those clones tend to

Finally, because our case study is conducted on Java soft-

have small numbers of token types. This means that there isware system, our method may not work on other language

the possibility of improving the eﬀectiveness of our method—4—

by use of the metric TKS in addition to the use of the metric RNR. However, clone sets with low RNR value include a[8]

lot of consecutive parts. They tend to have small number oftoken types and low TKS value. This correlation means thatthe use of both TKS and RNR is not signiﬁcantly eﬀective.

[9]

Balazinska [3] et al. and Higo [7] et al. characterize clone
sets according to the ease of refactoring. Balazinska et al.
characterize clone sets by analyzing the following informa-

[10]
[11]

tion:
•

Diﬀerences among the code clones belonging to a clone

set
•

[12]

Dependencies between the code clone belonging to aclone set and its surrounding code
Higo [7] et al. proposed two metrics to represent the average number of the externally deﬁned variables respectively[13]

code clones in a Java software system. J. Softw. Maint.
Evol.: Res. Pract., 20:435–461, 2008.
L. Jiang, G. Misherghi, Z. Su, and S. Glondu. DECKARD:
Scalable and accurate tree-based detection of code clones.
In Proc. of ICSE 2007, pages 96–105, 2007.
Z. M. Jiang and A. E. Hassan. A framework for studying
clones in large software systems. In Proc. of SCAM 2007,
pages 203–212, 2007.
T. Kaimiya. Tutorial of CLI Tool ccfx, 2008. http://www.ccfinder.net/doc/10.2/en/tutorial-ccfx.html.
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.,
28(7):654–670, 2002.
C. J. Kapser and M. W. Godfrey. “Cloning consideredharmful” considered harmful: patterns of cloning in software. Empir Software Eng, 13:645–692, 2008.
Y. Ueda, T. Kamiya, S. Kusumoto, and K. Inoue. Gemini: Maintenance support environment based on code clone
analysis. In Proc. of METRICS 2002, pages 67–76, 2002.

referenced and assigned in the code clones belonging to aclone set. The combination of our method and the techniques focusing on the ease of refactoring has the possibility
to improve the eﬀectiveness of clone set ﬁltering.

6. Summary and Future WorkIn this paper, we conducted a case study of open source
software systems and discuss its result. We found that thatreasons why several clone sets are inappropriate for refactoring.
As future work, we are planning to perform case studies ofsoftware systems written without using Java. Moreover, we
would like to investigate recall and more metrics.

Acknowledgments
We express our great thanks to Ms. Fusako Mitsuhashi and
Mr. Shin ichi Iwasaki of NEC Corporation for data collection. This work is being conducted as a part of Stage Project.
Also, this work is partially supported by JSPS, Grant-in-Aid
for Scientic Research (A) (21240002) and Grant-in-Aid for
Research Activity start-up(22800040).
References[1] JBoss Application Server. http://www.jboss.org.
[2] The Apache Ant Project. http://ant.apache.org/.
[3] M. Balazinska, E. Merlo, M. Dagenais, B. Lagüe, andK. Kontogiannis.
Advanced clone-analysis to support
object-oriented system refactoring. In Proc. of WCRE 2000,
pages 98–107, 2000.
[4] E. Choi, N. Yoshida, T. Ishio, K. Inoue, and T. Sano. Extracting code clones for refactoring using combinations ofclone metrics. In Proc. of the IWSC 2011, pages 7–13, 2011.
[5] M. Fowler. Refactoring: improving the design of existingcode. Addison Wesley, 1999.
[6] Y. Higo, T. Kamiya, S. Kusumoto, and K. Inoue. Method
and Implementation for Investigating Code Clones in a Software System. Information and Software Technology, 49(910):985–998, 2007.
[7] Y. Higo, S. Kusumoto, and K. Inoue. A metric-based approach to identifying refactoring opportunities for merging—5—