Hindawi Publishing Corporation
Advances in Software Engineering
Volume 2012, Article ID 938296, 22 pages
doi:10.1155/2012/938296

Research Article
An Empirical Study on the Impact of Duplicate Code
Keisuke Hotta, Yui Sasaki, Yukiko Sano, Yoshiki Higo, and Shinji Kusumoto
Graduate School of Information Science and Technology, Osaka University, Osaka 565-0871, Japan
Correspondence should be addressed to Keisuke Hotta, k-hotta@ist.osaka-u.ac.jp
Received 4 January 2012; Accepted 5 March 2012
Academic Editor: Osamu Mizuno
Copyright © 2012 Keisuke Hotta et al. This is an open access article distributed under the Creative Commons Attribution License,
which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.
It is said that the presence of duplicate code is one of the factors that make software maintenance more diﬃcult. Many research
eﬀorts have been performed on detecting, removing, or managing duplicate code on this basis. However, some researchers doubt
this basis in recent years and have conducted empirical studies to investigate the influence of the presence of duplicate code. In thisstudy, we conduct an empirical study to investigate this matter from a diﬀerent standpoint from previous studies. In this study, wedefine a new indicator “modification frequency” to measure the impact of duplicate code and compare the values between duplicate
code and nonduplicate code. The features of this study are as follows the indicator used in this study is based on modification places
instead of the ratio of modified lines; we use multiple duplicate code detection tools to reduce biases of detection tools; and wecompare the result of the proposed method with other two investigation methods. The result shows that duplicate code tends
to be less frequently modified than nonduplicate code, and we found some instances that the proposed method can evaluate theinfluence of duplicate code more accurately than the existing investigation methods.

1. Introduction
Recently, duplicate code has received much attention. Duplicate code is also called as “code clone.” Duplicate code isdefined as identical or similar code fragments to each otherin the source code, and they are generated by various reasons
such as copy-and-paste programming. It is said that thepresence of duplicate code has negative impacts on softwaredevelopment and maintenance. For example, they increase
bug occurrences: if an instance of duplicate code is changed
for fixing bugs or adding new features, its correspondents
have to be changed simultaneously; if the correspondents
are not changed inadvertently, bugs are newly introduced tothem.
Various kinds of research eﬀorts have been performed
for resolving or improving the problems caused by thepresence of duplicate code. For example, there are currently
a variety of techniques available to detect duplicate code[1]. In addition, there are many research eﬀorts for merging
duplicate code as a single module like function or method,or for preventing duplications from being overlooked inmodification [2, 3]. However, there are precisely the opposite
opinions that code cloning is a good choice for design of thesource code [4].

In order to answer the question whether duplicate codeis harmful or not, several eﬀorts have proposed comparison
methods between duplicate code and nonduplicate code.
Each of them compares a characteristic of duplicate codeand nonduplicate code instead of directly investigating theirmaintenance cost. This is because measuring the actual
maintenance cost is quite diﬃcult. However, there is noconsensus on this matter.
In this paper, we conduct an empirical study thatcompares duplicate code to nonduplicate code from adiﬀerent standpoint of previous research and reports theexperimental result on open source software. The features of
the investigation method in this paper are as follows:(i) every line of code is investigated whether it is duplicate code or not; such a fine-grained investigation
can accurately judge whether every modification
conducted to duplicate code or to nonduplicate code;(ii) maintenance cost consists of not only source code
modification but also several phases prior to it; inorder to more appropriately estimate maintenancecost, we define an indicator that is not based on
modified lines of code but the number of modified
places;2

Advances in Software Engineering(iii) we evaluate and compare modifications of duplicate
code and nonduplicate code on multiple open source
software systems with multiple duplicate code detection tools, that is, because every detection tool detects
diﬀerent duplicate code from the same source code.

We also conducted a comparison experiment with two
previous investigation methods. The purpose of this experiment is to reveal whether comparisons between duplicate
code and nonduplicate code with diﬀerent methods yield thesame result or not. In addition, we carefully analyzed theresults in the cases that the comparison results were diﬀerent
from each method to reveal the causes behind the diﬀerences.
The rest of this paper is organized as follows: Section 2
describes related works and our motivation of this study.
Section 3 introduces the preliminaries. We situate ourresearch questions and propose a new investigation method
in Section 4. Section 5 describes the design of our experiments, then we report the results in Sections 6 and 7.
Section 8 discusses threats to validity, and Section 9 presents
the conclusion and future work of this study.

2. Motivation
2.1. Related Work. At present, there is a huge body of work on
empirical evidence on duplicate code shown in Table 1. The
pioneering report in this area is Kim et al.’s study on clone
genealogies [5]. They have conducted an empirical study on
two open source software systems and found 38% or 36%
of groups of duplicate code were consistently changed atleast one time. On the other hand, they observed that there
were groups of duplicate code that existed only for a shortperiod (5 or 10 revisions) because each instance of the groups
was modified inconsistently. Their work is the first empiricalevidence that a part of duplicate code increases the cost ofsource code modification.
However, Kapser and Godfrey have diﬀerent opinions
regarding duplicate code. They reported that duplicate code
can be a reasonable design decision based on the empirical
study on two large-scale open source systems [4]. They built
several patterns of duplicate code in the target systems, andthey discussed the pros and cons of duplicate code using thepatterns. Bettenburg et al. also reported that duplicate code
does not have much a negative impact on software quality[6]. They investigated inconsistent changes to duplicate codeat release level on two open software systems, and they foundthat only 1.26% to 3.23% of inconsistent changes introduced
software errors into the target systems.
Monden et al. investigated the relation between software
quality and duplicate code on the file unit [7]. They use
the number of revisions of every file as a barometer ofquality: if the number of revisions of a file is great, itsquality is low. Their experiment selected a large-scale legacy
system, which was being operated in a public institution,
as the target. The result showed that modules that included
duplicate code were 40% lower quality than modules that did
not include duplicate code. Moreover, they reported that thelarger duplicate code a source file included, the lower quality
it was.

Lozano et al. investigated whether the presence of
duplicate code was harmful or not [8]. They developed a tool,
CloneTracker, which traces which methods include duplicate
code (in short, duplicate method) and which methods are
modified in each revision. They conducted a pilot study, andfound that: duplicate methods tend to be more frequently
modified than nonduplicate methods; however, duplicate
methods tend to be modified less simultaneously than
nonduplicate methods. The fact implies that the presenceof duplicate code increased cost for modification, andprogrammers were not aware of the duplication, so thatthey sometimes overlooked code fragments that had to bemodified simultaneously.
Also, Lozano and Wermelinger investigated the impactof duplicate code on software maintenance [9]. Threebarometers were used in the investigation. The first one islikelihood, which indicates the possibility that the method
is modified in a revision. The second one is impact, whichindicates the number of methods that are simultaneously
modified with the method. The third one is work, which
can be represented as a product of likelihood and impact(work = likelihood × impact). They conducted a case study
on 4 open source systems for comparing the three barometersof methods including and not including duplicate code. The
result was that likelihood of methods including duplicate
code was not so diﬀerent from one of methods not including
duplicate code; there were some instances that impact of
methods including duplicate code were greater than oneof methods not including duplicate code; if duplicate code
existed in methods for a long time, their work tended toincrease greatly.
Moreover, Lozano et al. investigated the relation between
duplicate code, features of methods, and their changeability[10]. Changeability means the ease of modification. Ifchangeability decreased, it will be a bottleneck of software maintenance. The result showed that the presenceof duplicate code can decrease changeability. However,they found that changeability was more greatly aﬀected byother properties such as length, fan-out, and complexityof methods. Consequently, they concluded that it was notnecessary to consider duplicate code as a primary option.
Krinke hypothesized that if duplicate code is less stable
than nonduplicate code, maintenance cost for duplicate
code is greater than for nonduplicate code. He conducteda case study in order to investigate whether the hypothesis
is true or not [11]. The targets are 200 revisions (a version
per week) of source code of 5 large-scale open-source
systems. He measured added, deleted, and changed LOCs
on duplicate code and nonduplicate code and compared
them. He reported that nonduplicate code was more added,
deleted, and changed than duplicate code. Consequently,
he concluded that the presence of duplicate code did notnecessarily make it more diﬃcult to maintain source code.
Göde and Harder replicated Krinke’s experiment [12].
Krinke’s original experiment detected line-based duplicate
code meanwhile their experiment detected token-based
duplicate code. The experimental result was the same as
Krinke’s one. Duplicate code is more stable than nonduplicate code in the viewpoint of added and changed. On

Advances in Software Engineering

3
Table 1: Summarization of related work.

Kim et al. [5]Kapser and Godfrey [4]Bettenburg et al. [6]Monden et al. [7]Lozano et al. [8]Lozano and Wermelinger[9]
Lozano et al. [10]Krinke [11]Göde and Harder [12]Krinke [13]Rahman et al. [14]Göde and Koschke [15]How to investigate
Impact of duplicate code
Using clone linages and clone genealogies
A part of duplicate code is negative
Build several patterns of duplicate code and discuss about them
Nonnegative
Investigate inconsistent changes to duplicate code at the release revel
Nonnegative
Calculate the number of revisions on every file
Negative
Count the number of modifications on methods including duplicate code
Negative
Using work

A part of duplicate code is negative

Using changeability (the ease of modification)
Using stability (line level)
Using stability (token level)
Using ages
Investigate the relationship between duplicate code and bugs
Count the number of changes on clone genealogies

Negative but not so highNonnegative
Nonnegative
Nonnegative
Nonnegative
A part of duplicate code is negative

the other hand, from the deleted viewpoint, nonduplicate
code is more stable than duplicate code.
Also, Krinke conducted an empirical study to investigate
ages of duplicate code [13]. In this study, he calculated andcompared average ages of duplicate lines and nonduplicatelines on 4 large-scale Java software systems. He found thatthe average age of duplicate code is older than nonduplicate
code, which implies duplicate code is more stable than
nonduplicate code.
Eick et al. investigated whether source code decays when
it is operated and maintained for a long time [16]. They
selected several metrics such as the amount of added anddeleted code, the time required for modification, and thenumber of developers as indicators of code decay. The experimental result on a 15-year-operated large system showed thatcost required for completing a single requirement tendS to
increase.
Rahman et al. investigated the relationship between
duplicate code and bugs [14]. They analyzed 4 softwaresystems written in C language with bug information stored in
Bugzilla. They use Deckard, which is an AST-based detection
tool, to detect duplicate code. They reported that only a smallpart of the bugs located on duplicate code, and the presenceof duplicate code did not dominate bug appearances.
Göde modeled how type-1 code clones are generated andhow they evolved [17]. Type-1 code clone is a code clone thatis exactly identical to its correspondents except white spaces
and tabs. He applied the model to 9 open-source softwaresystems and investigated how code clones in them evolved.
The result showed that the ratio of code duplication was
decreasing as time passed; the average life time of code clones
was over 1 year; in the case that code clones were modified
inconsistently, there were a few instances that additional
modifications were performed to restore their consistency.
Also, Göde and Koschke conducted an empirical study
on clone evolution and performed a detailed tracking todetect when and how clones had been changed [15]. In theirstudy, they traced clone evolution and counted the numberof changes on each clone genealogy. They manually inspected

the result in one of the target systems and categorized all
the modifications on clones into consistent or inconsistent.
In addition, they carefully categorized inconsistent changes
into intentional or unintentional. They reported that almost
all clones were never changed or only once during their
lifetime, and only 3% of the modifications had high severity.
Therefore, they concluded that many of clones do not cause
additional change eﬀort, and it is important to identify theclones with high threat potential to manage duplicate code
eﬀectively.
As described above, some empirical studies reported that
duplicate code should have a negative impact on software
evolution meanwhile the others reported the opposite result.
At present, there is no consensus on the impact of the presence of duplicate code on software evolution. Consequently,
this research is performed as a replication of the previous
studies with solid settings.
2.2. Motivating Example. As described in Section 2.1, many
research eﬀorts have been performed on evaluating theinfluence of duplicate code. However, these investigation
methods still have some points that they did not evaluate. We
explain these points with the example shown in Figure 1. In
this example, there are two similar methods and some places
are modified. We classified these modifications into 4 parts,
modification A, B, C, and D.
Investigated Units. In some studies, large units (e.g., files
or methods) are used as their investigation units. In thoseinvestigation methods, it is assumed that duplicate code has
a negative impact if files or methods having a certain amountof duplicate code are modified, which can cause a problem.
The problem is the incorrectness of modifications count. For
example, if modifications are performed on a method which
has a certain amount of duplicate code, all the modifications
are assumed as performed on the duplicate code even if
they are actually performed on nonduplicate code of themethod. Modification C in Figure 1 is an instance of thisproblem. This modification is performed on nonduplicate

4Advances in Software Engineering

Revision R
public void highlight(Graph target) {public void highlight(Graph target) {if (target.isEmpty()) {return;}if (target.isEmpty()) {return;}Set<Node> nodes = target.getNodes();
Set<Node> uninterestNodes =new HashSet<Node>();for (Node node : target.getNodes()) {if (node.getEdges().isEmpty()) {uninterestNodes.add(node);

Set<Node> nodes = target.getNodes();
Set<Node> uninterestNodes =new HashSet<Node>();for (Node node : target.getNodes()) {if (node.getEdges().isEmpty()) {uninterestNodes.add(node);

}

}
}

}

nodes.removeAll(uninterestNodes);nodes.removeAll(uninterestNodes);System.out.println(“Processing Nodes”);
for(Node node : uninterestNodes) {drawLineThrough (node);}for (Node node : nodes) {addHighlight(node, Color.red);}for (Node node : nodes) {addHighlight(node, Color.red);}}
Duplicate code detected by both CCFinder &Scorpio}
Duplicate code detected by only Scorpio
Revision R + 1
public void highlight(Graph target) {public void highlight(Graph target) {if (target == null || target.isEmpty()) {}return;if (target == null || target.isEmpty()) {Modification A}

Set<Node> nodes = target.getNodes();return;Set<Node> nodes = target.getNodes();

Set<Node> uninterestNodes =new HashSet<Node>();for (Node node : target.getNodes()) {if (node.getEdges().isEmpty()) {uninterestNodes.add(node);

Modification B}}
nodes.removeAll(uninterestNodes);System.out.println(“Processing Nodes”);
for(Node node : uninterestNodes) {Modification C
for (Node node : nodes)
addHighlight(node, getColor());

paint (node, getPaintColor());}}
for (Node node : nodes) {addHighlight(node, getColor());}}}
Modification D

Figure 1: Motivating example.

Advances in Software Engineering
code; nevertheless, it is regarded that this modification is
performed on duplicate code if we use method as theinvestigation units.
Line-Based Barometers. In some studies, line-based barometers are used to measure the influence of duplicate codeon software evolution. Herein, the line-based barometer
indicates a barometer calculated with the amount of added/
changed/deleted lines of code. However, line-based barometer cannot distinguish the following two cases: the first case isthat consecutive 10 lines of code were modified for fixing a single
bug; the second case is that 1 line modification was performedon diﬀerent 10 places of code for fixing 10 diﬀerent bugs. In
real software maintenance, the latter requires much morecost than the former because we have to conduct several
steps before the actual source code modification such as
identifying buggy module, informing the maintainer about
the bugs, and identifying buggy instruction.
In Figure 1, Modification A is 1 line modification, andperformed on 2 places, meanwhile Modification B is 7 lines
modification on a single place. With line-based barometers,
it is regarded that Modification B has the impact 3.5 times
larger than Modification A. However, this is not true because
we have to identify 2 places of code for modifying A
meanwhile 1 place identification is required for B.
A Single Detection Tool. In the previous studies, a single
detection tool was used to detect duplicate code. However,there is neither a generic nor strict definition of duplicate
code. Each detection tool has its own unique definition of
duplicate code, and it detects duplicate code based on theown definition. Consequently, diﬀerent duplicate code is
detected by diﬀerent detection tools from the same sourcecode. Therefore, the investigation result with one detector is
diﬀerent from the result from another detector. In Figure 1,
a detector CCFinder detects lines highlighted with red as
duplicate code, and another detector Scorpio detects not
only lines highlighted with red but also lines highlighted withorange before modification. Therefore, if we use Scorpio,
Modification D is regarded as being aﬀected with duplicate
code, nevertheless, it is regarded as not being aﬀectedwith duplicate code if we use CCFinder. Consequently, theinvestigation with a single detector is not suﬃcient to get thegeneric result about the impact of duplicate code.
2.2.1. Objective of This Study. In this paper, we conducted
an empirical study from a diﬀerent standpoint of previous
research. The features of this study are as follows.

5
Multiply Detector. In this study, we use 4 duplicate code
detection tools to reduce biases of each detection method.

3. Preliminaries
In this section, we describe preliminaries used in this paper.
3.1. Duplicate Code Detection Tools. There are currently
various kinds of duplicate code detection tools. The detection
tools take the source code as their input data, and they
provide the position of the detected duplicate code in it. The
detection tools can be categorized based on their detection
techniques. Major categories should be line based, token
based, metrics based, AST (Abstract Syntax Tree) based, and
PDG (Program Dependence Graph) based. Each technique
has merits and demerits, and there is no technique thatis superior to any other techniques in every way [1, 18].
The following subsections describe 4 detection tools thatare used in this research. We use two token-based detection
tools, which is for investigating whether both the tokenbased detection tools always introduce the same result or not.
3.1.1. CCFinder. CCFinder is a token-based detection tool[19]. The major features of CCFinder are as follows.
(i) CCFinder replaces user-defined identifiers such as
variable names or function names with special
tokens before the matching process. Consequently,
CCFinder can identify code fragments that use
diﬀerent variables as duplicate code.
(ii) Detection speed is very fast. CCFinder can detects
duplicate code from millions lines of code within anhour.
(iii) CCFinder can handle multiple popular programming languages such as C/C++, Java, and COBOL.
3.1.2. CCFinderX. CCFinderX is a major version up from
CCFinder [20]. CCFinderX is a token-based detection tool
as well as CCFinder, but the detection algorithm waschanged to bucket sort to suﬃx tree. CCFinderX can handle
more programming languages than CCFinder. Moreover, it
can eﬀectively use resources of multi core CPUs for fasterdetection.

Fine-Grained Investigation Units. In this study, every line ofcode is investigated whether it is duplicate code or not, whichenables us to judge whether every modification is conductedon duplicate code or nonduplicate code.

3.1.3. Simian. Simian is a line-based detection tool [21].
As well as CCFinder family, Simian can handle multiple
programming languages. Its line-based technique realizes
duplicate code detection on small memory usage and shortrunning time. Also, Simian allows fine-grained settings. For
example, we can configure that duplicate code is not detectedfrom import statements in the case of Java language.

Place-Based Indicator. We define a new indicator based on
the number of modified places, not the number of modifiedlines. The purpose of place-based indicator is to evaluate
the impact of the presence of duplicate code with diﬀerent
standpoints from the previous research.

3.1.4. Scorpio. Scorpio is a PDG-based detection tool
[22, 23]. Scorpio builds a special PDG for duplicate code
detection, not traditional one. In traditional PDGs, there are
two types of edge representing data dependence and control
dependence. The special PDG used in Scorpio has one

6

Advances in Software Engineering(a) before modification
(1) A
(2) B
(3) line will be changed 1(4) line will be changed 2
(5) C
(6) D
(7) line will be deleted 1(8) line will be deleted 2(9) E(10) F(11) G(12) H(b) after modification
(1) A
(2) B
(3) line changed 1(4) line changed 2
(5) C
(6) D
(7) E
(8) F
(9) G
(10) line added 1(11) line added 2(12) H(c) diﬀ output
3,4c3,4< line will be changed 1< line will be changed 2--> line changed 1> line changed 2
7,8d6< line will be deleted 1< line will be deleted 2
11a10,11> line added 1> line added 2
Algorithm 1: A simple example of comparing two source files withdiff (changed region is represented with identifier “c” like 3,4c3,4;
deleted region is represented with identifier “d” like 7,8d6, added
region is represented with identifier “a” like 11a10,11). The number
before and after the identifier shows the correspond lines.

more edge, execution-next link, which allows detecting more
duplicate code than traditional PDG. Also, Scorpio adopts
some heuristics for filtering out false positives. Currently,
Scorpio can handle only Java language.
3.2. Revision. In this paper, we analyze historical data
managed by version control systems for investigation. Version control systems store information about changes todocuments or programs. We can specify changes by using
a number, “revision”. We can get source code in arbitrary
revision, and we can also get modified files, change logs, andthe name of developers who made changes in arbitrary twoconsecutive revisions with version control systems.
Due to the limit of implementation, we restrict the target
version control system to Subversion. However, it is possible
to use other version control systems such as CVS.
3.3. Target Revision. In this study, we are only interested
in changes in source files. Therefore, we find out revisions
that have some modifications in source files. We call such
revisions as target revisions. We regard a revision R as thetarget revision, if at least one source file is modified from R
to R + 1.
3.4. Modification Place. In this research, we use the numberof places of modified code, instead lines of modified code.
That is, even if multiple consecutive lines are modified,
we regard it as a single modification. In order to identify
the number of modifications, we use UNIX diﬀ command.
Algorithm 1 shows an example of diﬀ output. In thisexample, we can find 3 modification places. One is a change
in line 3 and 4, another is a deletion in line 7 and 8, and theother is an addition at line 11. As shown in the algorithm,
it is very easy to identify multiple consecutive modified lines
as a single modification; all we have to do is just parsing theoutput of diﬀ so that the start line and end line of all themodifications are identified.

4. Proposed Method
This section describes our research questions and the investigation method.
4.1. Research Questions and Hypotheses. The purpose of thisresearch is to reveal whether the presence of duplicate code
really aﬀects software evolution or not. We assume that if
duplicate code is more frequently modified than nonduplicate
code, the presence of duplicate code has a negative impact on
software evolution. This is because if much duplicate code isincluded in source code though, it is never modified during
its lifetime, the presence of duplicate code never causes
inconsistent changes or additional modification eﬀorts. Our
research questions are as follows.
RQ1: Is duplicate code more frequently modified than nonduplicate code?
RQ2: Are the comparison results of stability between
duplicate code and nonduplicate code diﬀerent frommultiple detection tools?
RQ3: Is duplicate code modified uniformly throughout its
lifetime?
RQ4: Are there any diﬀerences in the comparison results on
modification types?
To answer these research questions, we define an indicator, modification frequency (in short, MF). We measure andcompare MF of duplicate code (in short, MFd ) and MF of
nonduplicate code (in short, MFn ) for investigation.

Advances in Software Engineering

7

4.2. Modification Frequency
4.2.1. Definition. As described above, we use MF to estimate
the influence of duplicate code. MF is an indicator basedon the number of modified code, not lines of modified
code. This is because this research aims to investigate froma diﬀerent standpoint from previous research.
We define MFd in the formula:


MFd =

r ∈R MCd (r)

|R|

,

(1)

where R is a set of target revisions, MCd (r) is the number ofmodifications on duplicate code between revision r and r +1.
We also define MFn in the formula:


MFn =

r ∈R MCn (r)

|R|

,

(2)

where MCn (r) is the number of modifications on nonduplicate code between revision r and r + 1.
These values mean the average number of modifications
on duplicate code or nonduplicate code per revision. However, in these definitions, MFd and MFn are very aﬀected by
the amount of duplicate code included the source code. For
example, if the amount of duplicate code is very small, it isquite natural that the number of modifications on duplicate
code is much smaller than nonduplicate code. However,
if a small amount of duplicate code is included but it isquite frequently modified, we need additional maintenanceeﬀorts to judge whether its correspondents need the same
modifications or not. We cannot evaluate the influence of
duplicate code in these situations in these definitions.
In order to eliminate the bias of the amount of duplicate
code, we normalize the formulae (1) and (2) with the ratio ofduplicate code. Here, we assume that(i) LOCd (r) is the total lines of duplicate code in revisionr,(ii) LOCn (r) is the total lines of nonduplicate code on r,(iii) LOC(r) is the total lines of code on r, so that thefollowing formula is satisfied:
LOC(r) = LOCd (r) + LOCn (r).

(3)

Under these assumptions, the normalized MFd and MFn
are defined in the following formula:r ∈R MCd (r)LOC(r),×  r ∈R
|R|
LOCd (r)r ∈RMCn (r)
LOC(r)
normalized MFn = r ∈R.
×  r ∈R
|R|
LOC
n (r)
r ∈R

normalized MFd =(4)

In the reminder of this paper, the normalized MFd and
MFn are called as just MFd and MFn , respectively.
4.2.2. Measurement Steps. The MFd and MFn are measured
with the following steps,

Step 1. It identifies target revisions from the repositories oftarget software systems. Then, all the target revisions arechecked out into the local storage.
Step 2. It normalized all the source files in every target
revision.
Step 3. It detects duplicate code within every target revision.
Then, the detection result is analyzed in order to identify thefile path, the lines of all the detected duplicate code.
Step 4. It identifies diﬀerences between two consecutive
revisions. The start lines and the end lines of all thediﬀerences are stored.
Step 5. It counts the number of modifications on duplicate
code and nonduplicate code.
Step 6. It calculates MFd and MFn .
In the reminder of this subsection, we explain each stepof the measurement in detail.
Step 1. It obtains Target Revisions. In order to measure MFdand MFn , it is necessary to obtain the historical data of thesource code. As described above, we used a version control
system, Subversion, to obtain the historical data.
Firstly, we identify which files are modified, added, ordeleted in each revision and find out target revisions. After
identifying all the target revision from the historical data,
they are checked out into the local storage.
Step 2. It normalizes Source Files. In the Step 2, every source
file in all the target revisions is normalized with the following
rules:(i) deletes blank lines, code comments, and indents,(ii) deletes lines that consist of only a single open/close
brace, and the open/close brace is added to the end of
the previous line.
The presence of code comments influences the measurement of MFd and MFn . If a code comment is located within aduplicate code, it is regarded as a part of duplicate code even
if it is not a program instruction. Thus, the LOC of duplicate
code is counted greater than it really is. Also, there is nocommon rule how code comments should be treated if they
are located in the border of duplicate code and nonduplicate
code, which can cause a problem that a certain detection tool
regards such a code comment as duplicate code meanwhile
another tool regards it as nonduplicate code.
As mentioned above, the presence of code comments
makes it more diﬃcult to identify the position of duplicate
code accurately. Consequently, all the code comments are
removed completely. As well as code comments, diﬀerent
detection tools handle blank lines, indents, lines including
only a single open or close brace in diﬀerent ways, which
also influence the result of duplicate code detection. For thisreason, blank lines and indents are removed, and lines thatconsist of only a single open or close brace are removed, and8Advances in Software Engineering
Table 2: Target software systems—Experiment 1.
(a) Experiment 1.1

Name
EclEmma
FileZilla
FreeCol
SQuirrel SQL Client
WinMerge

DomainTesting
FTP
Game
Database
Text Processing

Programming language
Java
C++
Java
Java
C++

Number of Revisions
788
3,450
5,963
5,351
7,082

LOC (latest revision)
15,32887,282
89,661
207,376
130,283

Number of Revisions
14
59
98
128
141
312
100
165
190
420

LOC (latest revision)
3,854
19,6957,406
1,139
130,072
173,688
45,368
192,716
65,7901,214,570(b) Experiment 1.2

Name
ThreeCAM
DatabaseToUMLAdServerBeans
NatMonitor
OpenYMSG
QMailAdmin
Tritonn
Newsstar
Hamachi-GUI
GameScanner

Domain3D Modeling
Database
Web
Network (NAT)
Messenger
Mail
Database
Network (NNTP)
GUI, Network (VPN)
Game

Programming language
Java
Java
Java
Java
Java
C
C/C++
C
C
C/C++

Table 3: Overview of Investigation Methods.
MethodKrinke [11]Lozano andWermelinger[9]

Proposed method

TargetRevisions

A revision per
week

All

All

Investigation
Unit

Line

MethodPlace (consecutive
lines)

ratio of
Modified lines

Work

Modification
frequency

Measurethe removed open or close brace is added to the end of theprevious line.
Step 3. It detects Duplicate Code. In this step, duplicate code is
detected from every target revision, and the detection results
are stored into a database. Each detected duplicate code is
identified by 3-tuple (v, f , l), where v is the revision numberthat a given duplicate code was detected; f is the absolute
path to the source file where a given duplicate code exists;
l is a set of line numbers where duplicate code exists. Notethat storing only the start line and the end line of duplicate
code is not feasible because a part of duplicate code is noncontiguous.
This step is very time consuming. If the history of
the target software includes 1,000 revisions, duplicate code
detection is performed 1,000 times. However, this step is fully
automated, and no manual work is required.
Step 4. It identifies Diﬀerences between Two Consecutive
Revisions. In Step 4, we find out modification places between

two consecutive revisions with UNIX diﬀ command. As
described above, we can get this information by just parsing
the output of diﬀ.
Step 5. It Counts the Number of Modifications. In this step,
we count the number of modifications of duplicate codeand nonduplicate code with the results of the previous
two steps. Here, we assume the variable for the number ofmodifications of duplicate code is MCd , and the variable
for nonduplicate code is MCn . Firstly, MCd and MCn are
initialized with 0, then they are increased as follows; if
the range of specified modification is completely included
in duplicate code, MCd is incremented; if it is completely
included in nonduplicate code, MCn is incremented; if it isincluded in both of duplicate code and nonduplicate code,
both MCd and MCn are incremented. All the modifications
are processed with the above algorithm.
Step 6. It calculates MFd and MFn . Finally, MFd and MFn
defined in the formula (4) are calculated with the result of
the previous step.

5. Design of Experiment
In this paper, we conduct the following two experiments.
Experiment 1. Compare MFd and MFn on 15 open-source
software systems.
Experiment 2. Compare the result of the proposed methodwith 2 previous investigation methods on 5 open-source
software systems.

Advances in Software Engineering

9
Table 4: Target software systems—Experiment 2.

Name
OpenYMSG
EclEmma
MASU
TVBrowser
Ant

DomainMessenger
Testing
Source Code Analysis
Multimedia
Build

Programming language
Java
Java
Java
Java
Java

We describe these experiments in detail in the reminderof this section.
5.1. Experiment 1
5.1.1. Outline. The purpose of this experiment is to answer
our research questions. This experiment consists of thefollowing two subexperiments.

Number of Revisions
194
1,220
1,620
6,829
5,412

Table 5: Ratio of duplicate code—Experiment 1.
(a) Experiment 1.1

Software Name
EclEmma
FileZilla
FreeCol
SQuirrel
WinMerge

Experiment 1.1. We compare MFd and MFn on various size
software systems with a scalable detection tool, CCFinder.
Experiment 1.2. We compare MFd and MFn on small
size software systems with 4 detection tools, described in
Section 3.1.
The reason why we choose only a single clone detector,
CCFinder, on Experiment 1.1 is that the experiment tookmuch time. For instance, we took a week to conduct theexperiment on SQuirrel SQL Client.
The following items are investigated in each subexperiment.
Item A. Investigate whether duplicate code is modified more
frequently than nonduplicate code. In this investigation, we
calculate MFd and MFn on the entire period.

LOC (latest revision)
14,111
31,40979,360264,796
198,864

ccf
13.1%
22.6%
23.1%
29.0%
23.6%

ccfx
—
—
—
—
—

sim
—
—
—
—
—

sco
—
—
—
—
—

sim
4.1%
7.6%
20.3%
0.7%
5.8%
8.8%
5.5%
1.5%
18.5%
6.6%

sco
26.2%
11.8%
15.9%
6.6%
9.9%
—
—
—
—
—

(b) Experiment 1.2

Software Name
ThreeCAM
DatabaseToUMLAdServerBeans
NatMonitor
OpenYMSG
QMailAdmin
Tritonn
Newsstar
Hamachi-GUI
GameScanner

ccf
29.8%
21.4%
22.7%
9.0%
17.4%
34.3%
13.8%
7.9%
36.5%
23.1%

ccfx
10.5%
25.1%
18.2%
7.7%
9.9%
19.6%
7.5%
4.8%
23.1%
13.1%

5.2. Experiment 2

Item B. Investigate whether MF tendencies diﬀer according
to the time.
To answer RQ1, we use the result of Item A of Experiments 1.1 and 1.2. For RQ2, we use the result of Item A
of Experiment 1.1. For RQ3, we use Item B of Experiment
1.1 and Experiment 1.2. Finally, for RQ4, we use Item A of
Experiment 1.1 and Experiment 1.2.

5.2.1. Outline. In Experiment 2, we compare the resultsof the proposed method and two previously described
investigation methods on the same targets. The purpose ofthis experiment is to reveal whether comparisons of duplicate
code and nonduplicate code with diﬀerent methods always
introduce the same result. Also, we evaluate the eﬃcacy ofthe proposed method comparing to the other methods.

5.1.2. Target Software Systems. In Experiment 1, we select15 open source software systems shown in Table 2 as
investigation targets. 5 software systems are investigatedin Experiment 1.1, and the other software systems areinvestigated in Experiment 1.2. The criteria for these target
software systems are as follows:

5.2.2. Investigation Methods to Be Compared. Here, we
describe 2 investigation methods used in Experiment 2.
We choose investigation methods proposed by Krinke [11](in short, Krinke’s method) and proposed by Lozano andWermelinger [9] (in short, Lozano’s method). Table 3 shows
the overview of these methods and the proposed method.
The selection was performed based on the following criteria.

(i) the source code is managed with Subversion;(ii) the source code is written in C/C++ or Java;(iii) we took care not to bias the domains of the targets.

(i) The investigation is based on the comparison somecharacteristics between duplicate code and nonduplicate code.

10

Advances in Software Engineering(ii) The method has been published at the time when our
research started (at 2010/9).

In the experiments of Krinke’s and Lozano’s papers, onlya single detection tool Simian or CCFinder was selected.
However, in this experiment, we selected 4 detection tools
for bringing more valid results.
We developed software tools for Krinke’s and Lozano’s
methods based on their papers. We describe Krinke’s methodand Lozano’s method briefly.

Table 6: Overall results—Experiment 1.
(a) Experiment 1.1

Software Name
EclEmma
FileZilla
FreeCol
SQuirrel
WinMerge

ccf
N
N
N
N
N

ccfx
—
—
—
—
—

sim
—
—
—
—
—

sco
—
—
—
—
—

sim
N
N
N
N
C
C
N
N
N
N

sco
N
N
N
C
N
—
—
—
—
—

(b) Experiment 1.2

Krinke’s Method. Krinke’s method compares stability of
duplicate code and nonduplicate code [11]. Stability is
calculated based on ratios of modified duplicate code andmodified nonduplicate code. This method uses not all therevisions but a revision per week.
First of all, a revision is extracted from every weekhistory. Then, duplicate code is detected from every of theextracted revisions. Next, every consecutive two revisions
are compared for obtaining where added lines, deleted lines,
and changed lines are. With this information, the ratios ofadded lines, deleted lines, and changed lines on duplicate andnonduplicate code are calculated and compared.
Lozano’s Method. Lozano’s method categorized Java methods, then compare distributions of maintenance cost basedon the categories [9].
Firstly, Java methods are traced based on their ownerclass’s full qualified name, start/end lines, and signatures.
Methods are categorized as follows:
AC-Method. Methods that always had duplicate code
during their lifetime;
NC-Method. Methods that never had duplicate code
during their lifetime;
SC-Method. Methods that sometimes had duplicate
code and sometimes did not.
Lozano’s method defines the followings where m is amethod, P is a period (a set of revisions), and r is a revision.
(i) ChangedRevisions(m, P): a set of revisions thatmethod m is modified in period P,(ii) Methods(r): a set of methods that exist in revision r,(iii) ChangedMethods(r): a set of methods that weremodified in revision r,(iv) CoChangedMethods(m, r): a set of methods thatwere modified simultaneously with method m inrevision r. If method m is not modified in revisionr, it becomes 0. If modified, the following formula issatisfied:

Software Name
ThreeCAM
DatabaseToUMLAdServerBeans
NatMonitor
OpenYMSG
QMailAdmin
Tritonn
Newsstar
Hamachi-GUI
GameScanner

ccf
N
N
N
C
C
C
N
N
N
C

ccfx
C
N
N
C
C
C
C
N
N
C

Then, this method calculates the following formulae withthe above definitions. Especially, work is an indicator of themaintenance cost:
ChangedRevisions(m, P),likelihood(m, P) =  r ∈P ChangedMethods(r)impact(m, P)


=

r ∈P



CoChangedMethods(m, r)/ |Methods(r)|,ChangedRevisions(m, P)

work(m, P) = likelihood(m, P) × impact(m, P).
(6)
In this research, we compare work between AC-Method
and NC-Method. In addition, we also compare SC-Methods’
work on duplicate period and nonduplicate period.
5.2.3. Target Software Systems. We chose 5 open-source
software systems in Experiment 2. Table 4 shows them. Twotargets, OpenYMSG and EclEmma, are selected as well as
Experiment 1. Note that the number of revisions and LOCof the latest revision of these two targets are diﬀerent from
Table 2. This is because they had been being in development
between the time-lag in Experiments 1 and 2. Every source
file is normalized with the rules described in Section 4.2.2 aswell as Experiment 1. In addition, automatically generated
code and testing code are removed from all the revisions
before the investigation methods are applied.

6. Experiment 1—Result and Discussion
ChangedMethod(r) = m ∪ CoChangedMethod(m, r).
(5)

6.1. Overview. Table 5 shows the average ratio for each targetof Experiment 1. Note that “ccf,” “ccfx,” “sim,” and “sco” in

20
15
10
5
0

11

MF

Advances in Software Engineeringdn
EclEmmadnFileZilladnFreeColdnSquirreldnWinMerge

25
20
15
10
5
0

d n d n d n d n d n d n d n d n d n d n
1

2

3

ChangeDeleteAdd

MF

Table 7: The average values of MF in Experiment 1.1.

Duplicate code
7.03371.0216
1.953910.0092MF
Nonduplicate code
8.10391.48473.737813.326489

106.2. Result of Experiment 1.1. Figure 2 shows all the resultsof Item A on Experiment 1.1. The labels “d” and “n” in Xaxis means MF in duplicate code and nonduplicate code,
respectively, and every bar consists of three parts, whichmeans change, delete, and add. As shown in Figure 2, MFd
is lower than MFn on all the target systems. Table 7 shows theaverage values of MF based on the modification types. The
comparison results of MFd and MFn show that MFd is lessthan MFn in the cases of all the modification types. However,the degrees of diﬀerences between MFd and MFn are diﬀerent
for each modification type.
For Item B on Experiment 1.1, first, we divide the entire
period into 10 sub-periods and calculate MF on every of the
sub periods. Figure 3 shows the result. X-axis is the divided
periods. Label “1” is the earliest period of the development,
and label “10” is the most recent period. In the case of
EclEmma, the number of periods that MFd is greater thanMFn is the same as the number of periods that MFn is greaterthan MFd . In the case of FileZilla, FreeCol, and WinMerge,
there is only a period that MFd is greater than MFn . Ind n d n d n d n d n d n d n d n d n d n
2

3

4

5

6

7

8

9

10

Time period(b) FileZilla

25
20
15
10
5
0

d n d n d n d n d n d n d n d n d n d n
1

2

3

4

5
6
7
Time period

8

9

10

MF

(c) FreeCol

40
30
20
10
0

d n d n d n d n d n d n d n d n d n d n
1

2

3

4

5
6
7
Time period

8

9

10

(d) SQuirrelMF

the table are the abbreviated form of CCFinder, CCFinderX,
Simian, and Scorpio, respectively.
Table 6 shows the overall result of Experiment 1. In
this table, “C” means MFd > MFn in that case, and “N”
means the opposing result. For example, the comparison
result in ThreeCAM with CCFinder is MFd < MFn , whichmeans duplicate code is not modified more frequently than
nonduplicate code. Note that “—” means the cases that we
do not consider because of the following reasons: (1) in
Experiment 1.1, we use only CCFinder, so that the cases withother detectors are not considered; (2) Scorpio can handle
only Java, so that the cases in software systems written in
C/C++ with Scorpio are not considered.
We describe the results in detail in the following subsections.

20
15
10
5
0

1

MF

ChangeDelete
Add
ALL

5
6
7
Time period(a) EclEmma

Figure 2: Result of Item A on Experiment 1.1.

Modification Type

4

25
20
15
10
5
0

d n d n d n d n d n d n d n d n d n d n
1

2

3

4

5
6
7
Time period

8

9

10

(e) WinMerge

Figure 3: Result of Item B on Experiment 1.1 (divided into 10
periods).

the case of Squirrel SQL Client, MFn is greater than MFd
in all the periods. This result implies that if the numberof revisions becomes large, duplicate code tends to become
more stable than nonduplicate code. However, the shapes ofMF transitions are diﬀerent from every software system.
For WinMerge, we investigated period “2,” where MFn ismuch greater than MFd , and period “10,” where is only the12Advances in Software Engineering

Table 8: Comparing MFs based on programming language anddetection tool.

Programming language
Java
C/C++
ALL

Duplicate code
20.4370
49.4868
32.8869

MF(a) Comparison on programming language

12MF
Nonduplicate code
24.173957.2246
38.3384

ChangeDeleteAdd
ALL

Duplicate code
26.80653.8706
2.209832.8869

n

d

n

d

n

d

n

MF

8
4
0

d

n

d

Beta–3.0.0

nd

3.0.0–3.1.0
Versionn

3.1.0–3.2.0(b) FileZilla

30

MF
Nonduplicate code
29.2549
3.52285.560838.3384

period that MFd is greater than MFn . In period “10,” there aremany modifications on test cases. The number of revisions
that test cases are modified is 49, and the ratio of duplicate
code in test cases is 88.3%. Almost all modifications for test
cases are performed on duplicate code, so that MFd is greaterthan MFn . Omitting the modifications for test cases, MFd
and MFn became inverted. However, there is no modificationon test cases in period “2,” so that MFd is less than MFn in thiscase.
Moreover, we divide the entire period by release dates andcalculate MF on every period. Figure 4 shows the result. As
the figure shows, MFd is less than MFn in all the cases for
FileZilla, FreeCol, SQuirrel, and WinMerge. For EclEmma,
there are some cases that MFd > MFn at the release level.
Especially, duplicate code is frequently modified in the early
releases.
Although MFd is greater than MFn in the period “6”in Freecol and the period “10” in WinMerge, MFd is lessthan MFn in all cases at the release level. This indicates that
duplicate code is sometimes modified intensively in a shortperiod, nevertheless it is stable than nonduplicate code in along term.
The summary of Experiment 1 is that duplicate code
detected by CCFinder was modified less frequently than
nonduplicate code. Consequently, we conclude that duplicate
code detected by CCFinder does not have a negative impact
on software evolution even if the target software is large andits period is long.

d(a) EclEmma

20
10
0

d

n

d

n

d

n

d

n

d

n

0.3.0–0.4.0 0.4.0–0.5.0 0.5.0–0.6.0 0.6.0–0.7.0 0.7.0–0.8.0
Version(c) FreeCol

30
MF

Modification type

n

12

MF

Table 9: The average values of MF in Experiment 1.2.

d0.1.1–1.0.0 1.0.0–1.1.0 1.1.0–1.2.0 1.2.0–1.3.0 1.3.0–1.4.0
Version20
10
0

d n d n d n d n d n d n d n d n
1.1–2.0 2.0–2.1 2.1–2.2 2.2–2.3 2.3–2.4 2.4–2.5 2.5–2.6 2.6–3.0
Version(d) SQuirrel

MF

CCFinderCCFinderX
SimianScorpioALL

Duplicate code
38.2790
40.3541
26.0084
20.9254
32.8869MF
Nonduplicate code
40.721140.0774
42.1643
24.1628
38.3384

40(b) Comparison on detection tool

Detection tool

8

20
15
10
5
0

d n d n d n d n d n d n d n
1.7–2.0 2.0–2.2 2.2–2.4 2.4–2.6 2.6–2.8 2.8–2.10 2.10–2.12
Version(e) WinMerge

Figure 4: Result of Item B on Experiment 1.1 (divided by releases).

6.3. Result of Experiment 1.2. Figure 5 shows all the results of
Item A on Experiment 1.2. In Figure 5, the detection tools
are abbreviated as follows: CCFinder → C; CCFinderX →X; Simian → Si;Scorpio → Sc. There are the results of 3
detection tools except Scorpio on C/C++ systems, because
Scorpio does not handle C/C++. MFd is less than MFn in
the 22 comparison results out of 35. In the 4 target systems
out of 10, duplicate code is modified less frequently than

MF

Advances in Software Engineering
80
70
60
50
40
30
20
10
0

13

d n d n d n d n d n d n d n d n d n d n d n d n d n d n d n d n d n d n d n d n
C

X

Si

Sc

ThreeCAM

C

X

Si

Sc

C

DatabaseToUML

X

Si

Sc

C

X

AdserverBeans

Si

Sc

C

NatMonitor

X

Si

Sc

OpenYMSG

ChangeDeleteAdd(a) Java software

250

MF

200
150
100
50
0

d

n d
C

n d
X

QMailAdmin

n d
Si

n d
C

n d
X

n d
Si

n d
C

Tritonnn d
XNewsstar

n d
Si

n d
C

n d
X

n d
Si

Hamachi-GUI

n d
C

n d
X

n
Si

GameScanner(b) C/C++ Software

Figure 5: Result of Item A on Experiment 1.2.

nonduplicate code in the cases of all the detection tools.
In the case of the other 1 target system, MFd is greaterthan MFn in the cases of all the detection tools. In theremaining systems, the comparison result is diﬀerent for thedetection tools. Also, we compared MFd and MFn based onprogramming language and detection tools. The comparison
result is shown in Table 8. The result shows that MFd is lessthan MFn on all the programming language, and MFd isless than MFn on the 3 detectors, CCFinder, Simian, andScorpio, meanwhile the opposing result is shown in the caseof CCFinderX. We also compared MFd and MFn based on
modification types. The result is shown in Table 9. As shownin Table 9, MFd is less than MFn in the cases of change andaddition, meanwhile the opposing result is shown in the caseof deletion.
We investigated whether there is a statistically significant
diﬀerence between MFd and MFn by t-test. The result isthat, there is no diﬀerence between them where the levelof significance is 5%. Also, there is no significant diﬀerencein the comparison based on programming language anddetection tool.
For Item B on Experiment 1.2, we divide the whole
period into 10 subperiods likewise Experiment 1.1. Figure 6
shows the result. In this experiment, we observed that thetendencies of MF transitions loosely fall into three categories:(1) MFd is lower than MFn almost of all the divisions; (2)MFd is greater than MFn in the early divisions, meanwhile theopposite tendency is observed in the late divisions; (3) MFd isless than MFn in the early divisions, meanwhile the opposite

tendency is observed in the late divisions. Figure 6 shows theresult of the 3 systems on which we observed remarkabletendencies of every category.
In Figure 6(a), period “4” shows that MFn is greater than
MFd on all the detection tool meanwhile period “7” shows
exactly the opposite result. Also, in period “5,” there are
hardly diﬀerences between duplicate code and nonduplicate
code. We investigated the source code of period “4.” In
this period, many source files were created by copy-andpaste operations, and a large amount of duplicate code was
detected by each detection tool. The code generated by copyand-paste operations was very stable meanwhile the othersource files were modified as usual. This is the reason why
MFn is much greater than MFd in period “4.”Figure 6(b) shows that duplicate code tends to be modified more frequently than nonduplicate code in the anterior
half of the period meanwhile the opposite occurred in theposterior half. We found that there was a large number of
duplicate code that was repeatedly modified in the anterior
half. On the other hand, there was rarely such duplicate codein the posterior half.
Figure 6(c) shows the opposite result of Figure 6(b). Thatis, duplicate code was modified more frequently in theposterior half of the period. In the anterior half, the amountof duplication was very small, and modifications were rarely
performed on it. In the posterior half, amount of duplicate
code became large, and modifications were performed on
it repeatedly. In the case of Simian detection, no duplicate
code was detected except period “5.” This is because Simian

14

Advances in Software Engineering
250
200
150
100
50
0

dndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndn
C X Si Sc C X Si Sc C X Si Sc C X Si Sc C X Si Sc C X Si Sc C X Si Sc C X Si Sc C X Si Sc C X Si Sc
1

2

3

4

5

6

7

8

9

10

ChangeDeleteAdd(a) AdServerBeans

50
40
30
20
10
0
dndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndn
C X Si Sc C X Si Sc C X Si Sc C X Si Sc C X Si Sc C X Si Sc C X Si Sc C X Si Sc C X Si Sc C X Si Sc
1

2

3

4

5

6

7

8

9

10

ChangeDeleteAdd(b) OpenYMSG

60
50
40
30
20
10
0

dndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndn
C X Si Sc C X Si Sc C X Si Sc C X Si Sc C X Si Sc C X Si Sc C X Si Sc C X Si Sc C X Si Sc C X Si Sc
1

2

3

4

5

6

7

8

9

10

ChangeDeleteAdd(c) NatMonitor

Figure 6: Result of Item B on Experiment 1.2 (divided into 10 periods).

detects only the exact-match duplicate code meanwhile theother tools detect exact match and renamed duplicate codein the default setting.
In Experiment 1.1, we investigate MF tendencies at therelease level. However, we cannot apply the same investigation way to Experiment 1.2. This is because the target
software systems in Experiment 1.2 is not enough mature tohave multiple releases. Instead, we investigate MF tendencies

at the most fine-grained level, at the revision level. Figure 7
shows the result of the investigation at the revision level for
AdServerBeans, OpenYMSG, and NatMonitor. The X-axis ofeach graph indicates the value of MFd − MFn . Therefore, if
the value is greater than 0, MFd is greater than MFn at therevision and vice versa. For AdServerBeans, MF tendencies
are similar for every detection tool except revision 21 to 26.
For other 2 software systems, MF comparison results diﬀer

MFd − MFn

Advances in Software Engineering
250
200
150
100
50
0
−50 1
−100
−150
−200

15

11

21

31

41

61

51

71

81

91

(a) AdServerBeans200

MFd − MFn

150
100
50
0
−50

1

11

21

31

41

51

61

71

81

91

101

111

121

131 141

81

91

101

111

121

−100

(b) OpenYMSG

120

MFd − MFn

80
40
0
−40

1

11

21

31

41

51

61

71

−80

Average
Individual tool (4 lines)(c) NatMonitor

Figure 7: Result of Item B on Experiment 1-2 (for each revision).

from each detection tool in most of the revisions. As thefigures show, tendencies of MF transition diﬀer from clone
detectors nevertheless there seems to be small diﬀerences
between clone detectors in 10 sub-periods division. However,these graphs do not consider modification types. Therefore,
we cannot judge what type of modification frequently
occurred from the graphs.
The summary of Experiment 1.2 is as follows: we foundsome instances that duplicate code was modified more
frequently than nonduplicate code in a short period oneach detection tool; however, in the entire period, duplicate
code was modified less frequently than nonduplicate codeon every target software with all the detection tools. Consequently, we conclude that the presence of duplicate code does
not have a seriously-negative impact on software evolution.

we found a similar result in Experiment 1.2: 22 comparison
results out of 35 show that MFd is lower than MFn , also MFd
is lower than MFn in average. This result indicates that thepresence of duplicate code does not seriously aﬀect software
evolution, which is diﬀerent from the common belief.

6.4. Answers for RQs

RQ2: Are the comparison results of stability between duplicate
code and nonduplicate code diﬀerent from multiple detection
tools? The answer is Yes. In Experiment 1.2, the comparison
results with CCFinderX are diﬀerent from the results withother 3 detectors. Moreover, MFn is much greater than MFd
in the case of Simian. At present, we cannot find the causesof the diﬀerence of the comparison results. One of the causes
may be the ratio of duplicate code. The ratio of duplicate
code is quite diﬀerent for each detection tool on the same
software. However, we cannot see any relation between theratio of duplicate code and MF.

RQ1: Is duplicate code more frequently modified than nonduplicate code? The answer is No. In Experiment 1.1, we foundthat MFd is lower than MFn in all the target systems. Also,

RQ3: Is duplicate code modified uniformly throughout its
lifetime? The answer is No. In Item B of Experiments 1.1

16
and 1.2, there are some instances that duplicate code wasmodified more frequently than nonduplicate code in a shortperiod though MFd is less than MFn in the whole period.
However, these MFs tendencies depend on target softwaresystems, so that we cannot find characteristics of suchvariability.
RQ4: Are there any diﬀerences in the comparison results on
modification types? The answer is Yes. In Experiment 1.1,
MFd is less than MFn on all the modification types. However,there is a small diﬀerence between MFd and MFn in the caseof deletion, meanwhile there is a large diﬀerence in the caseof addition. In Experiment 1.2, MFd is less than MFn in thecases of change and addition. Especially, MFn is more than
twice as large as MFd in the case of addition. However, MFd
is greater than MFn in the case of deletion. These results
show that deletion tends to be aﬀected by duplicate code,
meanwhile addition tends not to be aﬀected by duplicate
code.
6.5. Discussion. In Experiment 1, we found that duplicate
code tends to be more stable than nonduplicate code, whichindicates that the presence of duplicate code does not have anegative impact on software evolution. We investigated how
the software evolved in the period, and we found that thefollowing activities should be a part of factors that duplicate
code is modified less frequently than nonduplicate code.
Reusing Stable Code. When implementing new functionalities, reusing stable code is a good way to reduce the numberof introduced bugs. If most of duplicate code is reused stablecode, MFd becomes less than MFn .
Using Generated Code. Automatically generated code israrely modified manually. Also, the generated code tends tobe duplicate code. Consequently, if the amount of generated
code is high, MFd will become less than MFn .
On the other hand, there are some cases that duplicate
code was more frequently modified than nonduplicate codein a short period. The period “7” on AdServerBeans (Experiment 1.2, Item B) is one of these instances. We analyzed thesource code of this period to detect why MFd was greater thanMFn in this period though the opposite results were shown in
the other periods. Through the analysis, we found that there
are some instances that the same modifications were applied
to multiple places of code.
Algorithm 2 shows an example of unstable duplicate
code. There are 5 code fragments that are similar tothis fragment. Firstly, lines labeled with “%” (shown in
Algorithm 2(b)) were modified to replace the getter methods
into directly accesses to fields. In the next, a line labeledwith “#” is removed (shown in Algorithm 2(c)). These two
modifications were concentrically conducted in period “7.”Reusing unstable code like this example can cause additionalcosts for software maintenance. Moreover, a code fragment
was not simultaneously changed with its correspondents atthe second modification. If this inconsistent change wasintroduced unintentionally, it might cause a bug. If so, thisAdvances in Software Engineering
Table 10: Ratio of duplicate code—Experiment 2.
Software Name
OpenYMSG
EclEmma
MASU
TVBrowser
Ant

ccf
12.4%
6.9%
25.6%
13.6%
13.9%

ccfx
6.2%
4.8%
26.5%
10.9%
12.1%

sim
2.7%
2.0%
11.3%
5.4%
6.2%

sco
5.5%
3.7%
15.4%
19.0%
15.6%

Table 11: Overall results—Experiment 2.
Software Name

OpenYMSG

EclEmma

MASU

TVBrowser

Ant

MethodProposed
KrinkeLozanoProposed
KrinkeLozanoProposed
KrinkeLozanoProposed
KrinkeLozanoProposed
KrinkeLozano

Tools
ccf
N
N
—
N
N
N
C
C
C
N
C
C
N
C
C

ccfx
C
C
—
N
N
N
N
C
C
N
C
C
N
C
C

sim
C
C
N
N
N
—
C
C
C
N
C
C
N
C
C

sco
N
N
—
N
C
—
C
C
C
N
C
C
N
C
C

is a typical situation that duplicate code aﬀects software
evolution.

7. Experiment 2—Result and Discussion
7.1. Overview. Table 10 shows the average ratios of duplicate
code in each target, and Table 11 shows the comparison
results of all the targets. In Table 11, “C” means that duplicate
code requires more cost than nonduplicate code, and “N”
means its opposite. The discriminant criteria of “C” and “N”
are diﬀerent in each investigation method.
In the proposed method, if MFd is lower than MFn , thecolumn is labeled with “C,” and the column is labeled with
“N” in its opposite case.
In Krinke’s method, if the ratio of changed and deletedlines of code on duplicate code is greater than changed anddeleted lines on nonduplicate code, the column is labeledwith “C,” and in its opposite case the column is labeled with“N.” Note that herein we do not consider added lines because
the amount of add is the lines of code added in the next
revision, not in the current target revision.
In Lozano’s method, if work in AC-Method is statisticallygreater than one in NC-Method, the column is labeled with“C.” On the other hand, if work in NC-Method is statisticallygreater than one in AC-Method, the column is labeled with“N.” Here, we use Mann-Whitney’s U test under setting

Advances in Software Engineering

17(a) Before Modification
int oﬀsetTmp = dataGridDisplayCriteria.getItemsPerPage() ∗(dataGridDisplayCriteria.getPage() -1);
if (oﬀsetTmp > 0) --oﬀsetTmp;
if (oﬀsetTmp < 0) oﬀsetTmp = 0;
final int oﬀset = oﬀsetTmp;
String sortColumn =dataGridDisplayCriteria.getSortColumn();
Order orderTmp =dataGridDisplayCriteria.getOrder().equals(AdServerBeansConstants.ASC) ?
Order.asc(sortColumn) :Order.desc(sortColumn);(b) After 1st Modification
int oﬀsetTmp = dataGridDisplayCriteria.getItemsPerPage() ∗(dataGridDisplayCriteria.getPage() -1);
if (oﬀsetTmp > 0) --oﬀsetTmp;
if (oﬀsetTmp < 0) oﬀsetTmp = 0;
final int oﬀset = oﬀsetTmp;
String sortColumn =%dataGridDisplayCriteria.sortColumn;
Order orderTmp =%dataGridDisplayCriteria.order.equals(AdServerBeansConstants.ASC) ?
Order.asc(sortColumn) :Order.desc(sortColumn);(c) After 2nd Modification
int oﬀsetTmp = dataGridDisplayCriteria.getItemsPerPage() ∗(dataGridDisplayCriteria.getPage() -1);#
if (oﬀsetTmp < 0) oﬀsetTmp = 0;
final int oﬀset = oﬀsetTmp;
String sortColumn =dataGridDisplayCriteria.sortColumn;
Order orderTmp =dataGridDisplayCriteria.order.equals(AdServerBeansConstants.ASC) ?
Order.asc(sortColumn) :Order.desc(sortColumn);
Algorithm 2: An example of unstable duplicate code.

5% as the level of significance. If there is no statisticallysignificant diﬀerence in AC- and NC-Method, we compare
work in duplicate period and nonduplicate period in SCMethod with Wlcoxon’s singed-rank test. We also set 5% as
the level of significance. If there is no statistically significant
diﬀerence, the column is labeled with “—.”As this table shows, diﬀerent methods and diﬀerent tools
brought almost the same result in the case of EclEmma and
MASU. On the other hand, in the case of other targets, we
get diﬀerent results with diﬀerent methods or diﬀerent tools.
Especially, in the case of TVBrowser and Ant, the proposed
method brought the opposite result to Lozano’s and Krinke’s
method.

7.2. Result of MASU. Herein, we show comparison figures of
MASU. Figure 8 shows the results of the proposed method. In
this case, all the detection tools except CCFinderX brought
the same result that duplicate code is more frequently
modified than nonduplicate code. Figure 9 shows the resultsof Krinke’s method on MASU. As this figure shows, thecomparison of all the detection detectors brought the same
result that duplicate code is less stable than nonduplicate
code. Figure 10 shows the results of Lozano’s method on
MASU with Simian. Figure 10(a) compares AC-Method
and NC-Method. X-axis indicates maintenance cost (work)
and Y -axis indicates cumulated frequency of methods. For
readability, we adopt logarithmic axis on X-axis. In this18

Advances in Software Engineering
100

25
20

80

15
10

60

0

(%)

5
d

n

d

ccf

n

d

ccfx

n

d

sim

40

n
sco

20
ChangeDeleteAdd

01Figure 8: Result of the proposed method on MASU.

100

1000

AC-methodNC-method(a) AC-Method versus NC-Method

100
80
60
d

n
ccf

d

n
ccfx

d

n
sim

d

n

(%)

1.4
1.2
1
0.8
0.6
0.4
0.2
0

10

40

sco

ChangeDeleteAdd

Figure 9: Result of Krinke’s method on MASU.

20
0
1

10

100

1000

Duplicate period
Nonduplicate period

case, AC-Method requires more maintenance cost than
NC-Method. Also, Figure 10(b) compares duplicate period
and nonduplicate period of SC-Method. In this case, themaintenance cost in duplicate period is greater than in
nonduplicate period.
In the case of MASU, Krinke’s method and Lozano’s
method regard duplicate code as requiring more cost than
nonduplicate code in the cases of all the detection tools.
The proposed method indicates that duplicate code is more
frequently modified than nonduplicate code with CCFinder,
Simian, and Scorpio. In addition, there is little diﬀerences
between MFd and MFn in the result of the proposed methodwith CCFinderX, which is the only case that duplicate code
is more stable than nonduplicate code. Considering all the
results, we can say that duplicate code has a negative impact
on software evolution on MASU. This result is reliablebecause all the investigation methods show such tendencies.
7.3. Result of OpenYMSG. Figures 11, 12, and 13 show
the result of the proposed method, Krinke’s method, andLozano’s method on OpenYMSG. In the cases of the
proposed method and Krinke’s method, duplicate code isregarded as having a negative impact with CCFinderX andSimian, meanwhile the opposing results are shown with
CCFinder and Scorpio. In Lozano’s method with Simian,
duplicate code is regarded as not having a negative impact.
Note that we omit the comparison figure on SC-Method(b) SC-Method

Figure 10: Result of Lozano’s Method on MASU with Simian.

because there are only 3 methods that are categorized into
SC-Method.
As these figures show, the comparison results are diﬀerent
for detection tools or investigation methods. Therefore, wecannot judge whether the presence of duplicate code has anegative impact or not on OpenYMSG.
7.4. Discussion. In the case of OpenYMSG, TVBrowser,and Ant, diﬀerent investigation methods and diﬀerent
tools brought opposing results. Figure 14 shows an actual
modification in Ant. Two methods were modified in thismodification. The hatching parts are detected duplicate codeand frames in them mean pairs of duplicate code between
two methods. Vertical arrows show modified lines between
this modification and the next (77 lines of code weremodified).
This modification is a refactoring, which extracts the
duplicate instructions from the two methods and merges
them as a new method. In the proposed method, there
are 2 modification places in duplicate code and 4 places
in nonduplicate code, so that MFd and MFn become 51.13
and 18.13, respectively. In Krinke’s method, DC + CC andAdvances in Software Engineering

19

30

100

25
80

20
15

60
(%)

10
5
0

40
d

n

d

n

d

ccfx

ccf

n

d

sim

n
sco

20
0

ChangeDeleteAdd

1Figure 11: Result of the proposed method on OpenYMSG.

10

100

1000

AC-methodNC-method

Figure 13: Result of Lozano’s method on OpenYMSG with Simian.
1.6
1.4
1.2
1
0.8
0.6
0.4
0.2
0
d

n
ccf

d

n
ccfx

d

n
sim

d

n
sco

ChangeDeleteAdd

Figure 12: Result of Krinke’s method on OpenYMSG.

DN + CN become 0.089 and 0.005, where DC, CC, DN,
and CN indicate the ratio of deleted lines on duplicate
code, changed lines on duplicate code, deleted lines on
nonduplicate code, and deleted lines on nonduplicate code,
respectively.
In this case, both the proposed method and Krinke’s
method regard duplicate code requiring more maintenancecost than nonduplicate code. However, there is a great
diﬀerence in Krinke’s method than the proposed method:in the proposed method, duplicate code is modified about
2.8 times as frequently as nonduplicate code; meanwhile,in Krinke’s method, duplicate code is modified 17.8 times
as frequently as nonduplicate code. This is caused by thediﬀerence of the barometers used in each method. In
Krinke’s method, the barometer depends on the amount ofmodified lines, meanwhile the barometer depends on theamount of modified places in the proposed method. This
example is one of the refactorings on duplicate code. In
Krinke’s method, if removed duplicate code is large, duplicate
code is regarded as having more influence. However, inthe cases of duplicate code removal, we have to spend
much eﬀort if the number of duplicate fragments is high.
Therefore, we can say that the proposed method canaccurately measure the influence of duplicate code in thiscase.

This is an instance that is advantageous for the proposed
method. However, we cannot investigate all the experimental
data because the amount of the data is too vast to conduct
manual checking for all the modifications. There is apossibility that the proposed method cannot accurately
evaluate the influence of duplicate code in some situations.
In Experiment 2, we found that the diﬀerent investigation methods or diﬀerent detectors draw diﬀerent resultson the same target systems. In Experiment 1, we found that
duplicate code is less frequently modified than nonduplicate
code. However, the result of Experiment 2 shows that wecannot generalize the result of Experiment 1. We have to
conduct more experiments and analyze the results of themin detail to gain more generic.

8. Threats to Validity
This section describes threats to validity of this study.
8.1. Features of Every Modification. In this study, we assume
that cost required for every modification is equal to one
another. However, the cost is diﬀerent between every modification in the actual software evolution. Consequently, thecomparison based on MF may not appropriately represent
the cost required for modifying duplicate code and nonduplicate code.
Also, when we modify duplicate code, we have toconsider maintaining the consistency between the modified
duplicate code and its correspondents. If the modification
lacks the consistency by error, we have to remodify them for
repairing the consistency. The eﬀort for consistency is notnecessary for modifying nonduplicate code. Consequently,
the average cost required for duplicate code may be diﬀerent
from the one required for nonduplicate code. In order tocompare them more appropriately, we have to consider thecost for maintaining consistency.
Moreover, distribution of source code that should be
modified are not considered. However, it diﬀers from20

Advances in Software Engineering
Code fragment 1

Code fragment 2

private void doClassicCompile() throws BuildException {log(“Using classic compiler”, Project.MSG VERBOSE);
7 lines
Path classPath = getCompileClasspath(false);...
argList.addElement(“-classpath”);
if (. . .) { . . .
} else {...
}if (debug) { . . . }...
log(“Compilation args: ” + argList.toString(),
Project.MSG VERBOSE);

17 lines

String[] args = new String[argList.size() + compileList.size()];...
Enumeration enum = compileList.elements();
while (enum.hasMoreElements()) { . . . }log(niceSourceList.toString(), Project.MSG VERBOSE);
ByteArrayOutputStream out = new ByteArrayOutputStream();
...
...

32
lines

}

private void doClassicCompile() throws BuildException {...
log(“Using classic compiler”, Project.MSG VERBOSE);
7 lines
Path classPath = getCompileClasspath(false);...
argList.addElement(“-classpath”);...
17 lines
if (debug) { . . . }...
log(“Compilation args: ” + argList.toString(),
Project.MSG VERBOSE);

38
lines

String[] args = new String[argList.size() + compileList.size()];...
Enumeration enum = compileList.elements();
while (enum.hasMoreElements()) { . . . }log(niceSourceList.toString(), Project.MSG VERBOSE);
...
...
}
Clone pair relationship
Modified lines between this revision and the next

Figure 14: An Example of Modification.

every modification, thus we may get diﬀerent results byconsidering the distribution of source code.
8.2. Identifying the Number of Modifications. In this study,
modifying consecutive multiple lines are regarded as asingle modification. However, it is possible that such an
automatically processing identifies the incorrect number ofmodifications. If multiple lines that were not contiguous
are modified for fixing a single bug, the proposed method
presumes that multiple modifications were performed. Also,if multiple consecutive lines were modified for fixing two or
more bugs by chance, the proposed method presumes that
only a single modification was performed. Consequently, it
is necessary to manually identify modifications if we have to
use the exactly correct number of modifications.
Besides, we investigated how many the identified modifications occurred across the boundary of duplicate code andnonduplicate code. If this number is high, then the analysis
suspects because such modifications increase both the counts
at the same time. The investigation result is that, in thehighest case, the ratio of such modifications is 4.8%. Thatmeans that almost all modifications occurred within either
duplicate code or nonduplicate code.
8.3. Category of Modifications. In this study, we counted all
the modifications, regardless of their categories. As a result,the number of modifications might be incorrectly increased
by unimportant modifications such as format transformation. A part of unimportant modifications remainedeven if we had used the normalized source code describedin Section 4.2.2. Consequently, manual categorization forthe modifications is required for using the exactly correct
number of modifications.

Also, the code normalization that we used in this study
removed all the comments in the source files. If considerable
cost was expended to make or change code comments on thedevelopment of the target systems, we incorrectly missed thecost.
8.4. Property of Target Software. In this study, we used only
open-source software systems, so that diﬀerent results may
be shown with industrial software systems. Some researchers
pointed out that industrial software systems include muchduplicate code [24, 25]. Consequently, duplicate code may
not be managed well in industrial software, which may
increase MFd . Also, properties of industrial software arequite diﬀerent from ones of open source software. In order
to investigate the impact of duplicate code on industrial
software, we have to compare MF on industrial software
itself.
8.5. Settings of Detection Tools. In this study, we used default
settings for all the detection tools. If we change the settings,
diﬀerent results will be shown.

9. Conclusion
This paper presented an empirical study on the impact ofthe presence of duplicate code on software evolution. We
assumed that if duplicate code is modified more frequently
than nonduplicate code, the presence of duplicate codeaﬀects software evolution and compared the stability of
duplicate code and nonduplicate code. To evaluate from adiﬀerent standpoint from previous studies, we used a new
indicator, modification frequency, which is calculated with
the number of modified places of code. Also, we used 4

Advances in Software Engineering
duplicate code detection tools to reduce the bias of duplicate
code detectors. We conducted an experiment on 15 opensource software systems, and the result showed that duplicate
code was less frequently modified than nonduplicate code.
We also found some cases that duplicate code was intensively
modified in a short period though duplicate code was stable
than nonduplicate code in the whole development period.
Moreover, we compared the proposed method to other2 investigation methods to evaluate the eﬃcacy of the
proposed method. We conducted an experiment on 5 opensource software systems, and in the cases of 2 targets, we got
the opposing results to other 2 methods. We investigated theresult in detail and found some instances that the proposed
method could evaluate more accurately than other methods.
In this study, we found that duplicate code tends to bestable than nonduplicate code. However, more studies are
required to generalize this result, because we found that
diﬀerent investigation methods may bring diﬀerent results.
As future work, we are going to conduct more studies withother settings to get the characteristics of harmful duplicate
code.

Acknowledgments
This research is being conducted as a part of the Stage Project,
the Development of Next Generation IT Infrastructure,
supported by the Ministry of Education, Culture, Sports,
Science, and Technology of Japan. This study has been
supported in part by Grant-in-Aid for Scientific Research(A) (21240002) and Grant-in-Aid for Exploratory Research(23650014) from the Japan Society for the Promotion of Science, and Grant-in-Aid for Young Scientists (B) (22700031)
from Ministry of Education, Science, Sports and Culture.
This paper is an extended version of earlier conference papers[26, 27].

References[1] S. Bellon, R. Koschke, G. Antoniol, J. Krinke, and E. Merlo,“Comparison and evaluation of clone detection tools,” IEEE
Transactions on Software Engineering, vol. 32, no. 10, pp. 804–
818, 2007.
[2] M. D. Wit, A. Zaidman, and A. V. Deursen, “Managing
code clones using dynamic change tracking and resolution?”in Proceedings of the 25th IEEE International Conference on
Software Maintenance (ICSM ’09), pp. 169–178, September
2009.
[3] M. P. Robillard, W. Coelho, and G. C. Murphy, “How eﬀective
developers investigate source code: an exploratory study,” IEEE
Transactions on Software Engineering, vol. 30, no. 12, pp. 889–
903, 2004.
[4] C. J. Kapser and M. W. Godfrey, “‘cloning considered harmful’considered harmful: patterns of cloning in software,” Empirical
Software Engineering, vol. 13, no. 6, pp. 645–692, 2008.
[5] M. Kim, V. Sazawal, D. Notkin, and G. C. Murphy, “Anempirical study of code clone genealogies,” in Proceedings ofthe 13th ACM SIGSOFT Symposium on the Foundations ofSoftware Engineering, pp. 187–196, September 2005.
[6] N. Bettenburg, W. Shang, W. M. Ibrahim, B. Adams, Y.
Zou, and A. E. Hassan, “An empirical study on inconsistent

21
changes to code clones at the release level,” Science of Computer
Programming, vol. 77, no. 6, pp. 760–776, 2012.
[7] A. Monden, D. Nakae, T. Kamiya, S. Sato, and K. Matsumoto,“Software quality analysis by code clones in industrial legacy
software,” in Proceedings of the 8th IEEE International Software
Metrics Symposium, pp. 87–94, June 2002.
[8] A. Lozano, M. Wermelinger, and B. Nuseibeh, “Evaluating
the harmfulness of cloning: a change based experiment,”in Proceedings of the 4th International Workshop on Mining
Software Repositories (MSR ’07), May 2007.
[9] A. Lozano and M. Wermelinger, “Assessing the eﬀect of clones
on changeability,” in Proceedings of the 24th International
Conference on Software Maintenance, pp. 227–236, September
2008.
[10] A. Lozano, M. Wermelinger, and B. Nuseibeh, “Evaluating therelation between changeability decay and the characteristics
of clones and methods,” in Proceedings of the 23rd IEEE/ACM
International Conference on Automated Software Engineering,pp. 100–109, September 2008.
[11] J. Krinke, “Is cloned code more stable than non-cloned code?”in Proceedings of the 8th IEEE International Working Conference
on Source Code Analysis and Manipulation, SCAM 2008, pp.
57–66, September 2008.
[12] N. Göde and J. Harder, “Clone stability,” in Proceedings ofthe 15th European Conference on Software Maintenance andReengineering (CSMR ’11), pp. 65–74, March 2011.
[13] J. Krinke, “Is cloned code older than non-cloned code?” in Proceedings of the 5th International Workshop on Software Clones(IWSC ’11), pp. 28–33, May 2011.
[14] F. Rahman, C. Bird, and P. Devanbu, “Clones: what is thatsmell?” in Proceedings of the 7th IEEE Working Conference on
Mining Software Repositories, pp. 72–81, May 2010.
[15] N. Göde and R. Koschke, “Frequency and risks of changes
to clones,” in 33rd International Conference on Software
Engineering (ICSE ’11), pp. 311–320, May 2011.
[16] S. G. Eick, T. L. Graves, A. F. Karr, U. S. Marron, and
A. Mockus, “Does code decay? Assessing the evidence fromchange management data,” IEEE Transactions on Software
Engineering, vol. 27, no. 1, pp. 1–12, 2001.
[17] N. Göde, “Evolution of type-1 clones,” in Proceedings of the 9thIEEE International Working Conference on Source Code Analysis
and Manipulation (SCAM ’09), pp. 77–86, September 2009.
[18] E. Burd and J. Bailey, “Evaluating clone detection tools foruse during preventative maintenance,” in Proceedings of the
2nd IEEE International Workshop on Source Code Analysis andManipulation, pp. 36–43, October 2002.
[19] T. Kamiya, S. Kusumoto, and K. Inoue, “CCFinder: a multilinguistic token-based code clone detection system for large scale
source code,” IEEE Transactions on Software Engineering, vol.
28, no. 7, pp. 654–670, 2002.
[20] CCFinderX, http://www.ccfinder.net/ccfinderx.html/.
[21] Simian, http://www.harukizaemon.com/simian/.
[22] Y. Higo and S. Kusumoto, “Code clone detection on specialized PDGs with heuristics,” in Proceedings of the 15th European Conference on Software Maintenance and Reengineering(CSMR ’11), pp. 75–84, March 2011.
[23] Scorpio, http://sdl.ist.osaka-u.ac.jp/∼higo/cgi-bin/moin.cgi/
Scorpio/.
[24] S. Ducasse, M. Rieger, and S. Demeyer, “Language independent approach for detecting duplicated code,” in Proceedingsof the 15th IEEE International Conference on Software Maintenance (ICSM ’99), pp. 109–118, September 1999.

22[25] S. Uchida, A. Monden, N. Ohsugi, T. Kamiya, K. I. Matsumoto,and H. Kudo, “Software analysis by code clones in open source
software,” Journal of Computer Information Systems, vol. 45,
no. 3, pp. 1–11, 2005.
[26] K. Hotta, Y. Sano, Y. Higo, and S. Kusumoto, “Is duplicate code
more frequently modified than non-duplicate code in software
evolution?: an empirical study on open source software,” inProceedings of the 4th the International Joint ERCIM Workshop
on Software Evolution and International Workshop on Principlesof Software Evolution, September 2010.
[27] Y. Sasaki, K. Hotta, Y. Higo, and S. Kusumoto, “Is duplicate
code good or bad? an empirical study with multiple investigation methods and multiple detection tools,” in Proceedingsof the 22nd International Symposium on Software Reliability
Engineering (ISSRE ’11), Hiroshima, Japan, November 2011.

Advances in Software Engineering