How Compact Will My System Be?
A Fully-Automated Way to Calculate LoC
Reduced by Clone Refactoring
Tasuku Nakagawa, Yoshiki Higo, Junnosuke Matsumoto, and Shinji Kusumoto
Graduate School of Information Science and Technology
Osaka University
1-5 Yamadaoka, Suita, Osaka, Japan{t-nakagw, higo, j-matumt, kusumoto}@ist.osaka-u.ac.jp
Abstract—A code clone (in short, clone) is a codefragment that is identical or similar to other codefragments in source code. The presence of clone is
known as bad smell, which is phenomena of source code
to be refactored. A motivation of refactoring (merging)clones is to reduce the size of source code. An existing
study proposed a technique to estimate reduced lines ofcode by merging clones; however, there are two issues
in the existing technique: (1) the existing techniquedoes not consider the refactorability of clones in spitethat it is diﬃcult or even impossible to merge someclones due to the limitation of programming languages;(2) in the case that multiple clones are overlapping,
the existing technique only considers one of themcan be merged. Due to the above issues, estimatedreducible LoC is occasionally diﬀerent from the actual
number. Consequently, in this research, we propose
a new technique to calculate a reducible LoC. The
proposed technique is free from the two issues, andit calculates a reducible LoC fully automatically. The
proposed technique performs a loop processing of (a)detecting clones, (b) merging them, (c) compiling theedited source files, and (d) testing them. After finishing
the loop, reducible LoC is calculated from the edited
source files. This paper also includes comparison resultsof the proposed technique and the existing one. In
the comparisons, we confirmed that a reducible LoC
which was calculated with considering refactorability
is 25% of a reducible LoC which was estimated without
considering refactorability. We also confirmed that the
proposed technique was able to merge clones that were
not counted in the existing technique.
Keywords-Software maintenance; code clone; refactoring;

I. Introduction
Changes are occasionally (or even continuously) added
to the source code after software systems have been released. A bunch of changes to the source code deteriorates its quality (e.g., collapsing its design, decreasing
the readability), so that the maintenance cost gets more
expensive [1], [2], [3]. The maintenance cost of the sourcecode is often estimated from its size or complexity [3].
In the case of large-scale software systems, an enormous
amount of money is required. If users of a software system
can estimate its number, they should be able to decide
whether they continue to use it or replace it with a newone [4].
A factor of deteriorating the quality of source code is thepresence of clones. A clone means a code fragment that is
identical or similar to other code fragments in the sourcecode. Clones get involved in both software development
and maintenance. The presence of clones makes the sourcecode redundant so that inconsistencies in source code tend
to happen unintentionally. Thus, from the perspectiveof maintainability of the source code, merging clones isimportant.
Merging clones is a well-known refactoring. Refactoringis defined as a set of operations to improve the internal
structure of the source code without altering its external
behavior [5]. Extract Method refactoring, which is one of
the most often performed refactorings, is a set of operations to extract a code fragment in an existing method asa new method. If duplicated code fragments are extracted
as a new method, the duplication is removed from thesource code. Removing clones by refactoring makes it
easier to keep consistencies in the source code because
we do not have to put the same changes on duplicatedcode in multiple places. However, there is a possibility thatrefactoring itself introduces a new bug in the source code.
Consequently, removing all clones without any special
reason is not realistic: a reasonable indicator is required
whether or not given clones should be refactored.
There is a study that estimates how many lines of code
(LoC) is reduced by removing clones in the assumptionthat the reduced LoC is used as a primary indicator of
the eﬀects of clone refactoring [6]. This assumption means
that, if a large number of LoC is reduced by clone refactoring, its eﬀect is large and it is a suﬃcient motivation
to remove the clones. The technique in the existing study
utilizes the position information of clones (the path of thefile including a given clone, start line and end line of thegiven clone). If multiple clones are overlapped with eachother, the technique selects only one of them by using thegreedy algorithm. The authors think there are two issues
in the existing technique.
• The first issue is that the existing technique does notconsider whether or not each clone can be removed.
Some clones are diﬃcult or even impossible to bemerged as a single module such as class or method
due to the limitation of programming languages. For
example, if a clone includes a return statement, extracting it as a new method does not preserve theoriginal behavior. In the original source code, the roleof the return statement is getting out the existing
method while in the refactored code, the role of the
return statement is getting out the new extractedmethod.
• The second issue is that in the case that clones
are overlapping, the existing technique only considers
merging one of the overlapped clones. However, even
if two clones are overlapping, both of them may beable to be merged. Thus, an estimated reducible LoC
may become a completely diﬀerent number from theactual reducible LoC.
Both of the issues stem from the lack of checking refactorability of clones in the existing technique. However, it
is not realistic to manually check whether or not each of
the detected clones can be merged.
In this research, we propose a new technique to calculate
reducible LoC. The proposed technique performs a loop of(1) detecting clones, removing a set of clones, (3) compilingand testing the edited source code as long as the LoC of
the source code gets decreased by the refactorings. Dueto its nature, the proposed technique is completely freefrom the above two issues. We implemented a softwaretool based on the proposed technique and applied it toseveral open source software systems. The purpose of theapplication is comparing the proposed technique to theexisting one. As a result, we confirmed that the proposed
technique calculated diﬀerent reducible LoC values fromthe existing technique.
The remainder of this paper is organized as follows: we
describe the preliminaries of this research in Section II; we
explain the proposed technique in Section III; section IV is
an introduction of the implemented tool; in Section V, weshow and discuss the comparison results with the existing
technique; in Section VI, we notice threats to validity ofthe proposed technique and the experiment; finally, we
conclude this paper in Section VII.
II. Preliminaries
A. Clone Detection
A clone is a code fragment that is identical or similar
to another code fragment [7]. A pair of code fragmentsthat are identical or similar to each other is called clone
pair. A set of code fragments in which any pair is a clone
pair is called clone set. Reusing source code by copy-andpaste operations gets accelerated code implementation,
but clones occurred to make it more diﬃcult to maintainthe source code [8]. For example, if a bug happens in acode fragment, developers need to check whether or not
the similar bug exists in each of its clones. Consequently,
it is important to understand where and how many clones
exist in the source code.
So far, many clones detection techniques and tools
have been proposed and developed [7], [9], [10]. However,there is no generic and strict definition of clones. Eachclone detection technique has its unique definition anddetects clones based on the definition. Thus, diﬀerent clone
detection techniques detect diﬀerent clones from the same
source code.

void printTaxi(amount) {String name = getTaxiName();print("name: " + name);print("amount: " + amount);}
void printBus(amount){
String name = getBusName();print("name: " + name);print("amount: " + amount);}

void printTaxi(amount) {String name = getTaxiName();print(name, amount);}

void printBus(amount){
String name = getBusName();print(name, amount);}
void printFare(name, amount){
print("name: " + name);print("amount: " + amount);}

Fig. 1: Extract method refactoring
In this paper, we introduce a couple of popular detection
techniques that are especially related to this research.
Token-based Clone Detection
This technique firstly translates the target source code
to a sequence of tokens, then duplicated subsequences aredetected as clones. Some normalizations are often applied
before detecting subsequences. For example, user-defined
identifiers such as variable names are replaced with special tokens. By applying this normalization, token-based
detection technique can detect clones even if they include
diﬀerent variable names. The detection speed of tokenbased techniques are quite high, but detected clones are
not necessarily suited for refactoring because token-based
clones do not match with structural units of programming
languages such as classes, methods or internal blocks inmethods. CCFinder [7] and its successor CCFinderX [11]are well-known token-based detection tools.
AST-based Clone Detection
In this technique, abstract syntax trees (in short, AST)
are generated from the target source code. The isomorphic subtrees in the ASTs are identified as clones. Eachdetected clone corresponds to either structural unit of
the programming language since it is a subtree in the
ASTs. Consequently, clones detected by AST-based clone
techniques have much better chemistry with refactoring
than token-based clones. Deckard [9] is a well-known ASTbased detection tool.
B. Refactoring Clone
Refactoring is known as a promising technique to improve the internal structure of source code without changing its external behavior [5]. Duplicated code (clones) is
one of the typical bad smells (code to be refactored). There
are a variety of ways to refactor (merge) clones. Extract
Method refactoring is a simple yet well-known techniqueto remove clones. The original purpose of this refactoring
pattern simplifies a long and/or complicated method byextracting a part of it as a new method. However, byapplying Extract Method refactoring to clones, they canbe removed. Figure 1 shows a simple example of Extract
Method refactoring to two duplicated code fragments.
There are two major eﬀects on applying Extract Method
refactoring to a set of clones.

Clone A
Clone B

File A

File B
File C(a) Overlapped clone

M = Csize + 2
Clone A
Clone B

File A

File B
File C(b) Removing either one

Clone A'
Clone B
Clone C

File A

LoC of a method becomes LoC of the method body plus
two. An extracted code fragment (a clone) becomes a bodyof the new method. Consequently, LoC of the extracted
method can be represented with the following formula.

File B
File C(c) Clone dividing

Fig. 2: Clone overlapping
Code duplications are removed, which makes it easier
to maintain consistency in the source code.
• LoC of the source code is changed; in many cases, LoC
gets reduced. How many LoC is reduced depends on
the size of a clone and the number of clones.
•

C. Clone Overlapping
In this paper, when two or more clones share one ormore tokens, we say that “the clones are overlapped witheach other”. Figure 2a shows an example of overlapped
clones. In this figure, clone A includes clone B. Whenclones are overlapped like this figure, we need to do special
care to estimate reducible LoC. For example, the existing
technique in literature [6] estimates reducible LoC in thecase of removing clone A and in case of removing clone
B separately, and then remove only either A or B, whose
reducible LoC is larger than the other. Literature [6] also
proposes a more aggressive approach, which is shown in
Figure 2c. In this approach, the overlapped parts andthe non-overlapped parts are separately considered forrefactoring.
D. Reducible LoC
Herein, we introduce the definition of reducible LoC,
which is proposed in the existing technique [6]. Herein, we
assume that a clone set includes n code fragments, andeach code fragment consists of Csize LoC. In a refactoringof merging the clone set, each clone is replaced with amethod invocation, which is usually 1-line code. Consequently, reducible LoC Call can be represented with thefollowing formula.
Call = n ∗ Csize − n(1)
In the case of Java, there is a 1-line code of method
signature and open bracket “{” before a method body, andthere is another 1-line code of close bracket “}”. Thus, the(2)

By using the two formula 1 and 2, the LoC diﬀerence
between the original code and refactored code can be
represented with the following formula.
S = Call − M = (n − 1) ∗ Csize − n + 2(3)
In the existing technique [6], the above formula isused to estimate reducible LoC by removing clones. As
mentioned above, if multiple clones are overlapped witheach other, the existing technique decides which clone
is refactored by using the greedy algorithm. The literature [6] addresses that estimated reducible LoC by using
the greedy algorithm is practical. However, the existing
technique inherently includes the two issues that we mentioned in Subsection II-B.
III. proposed technique
We propose a new technique to calculate LoC that canbe reduced by merging clones. The technique repeats (1)detecting clones, (2) editing source files, (3) compiling,and (4) testing. This technique enables users to obtain
actual LoC that can be reduced by merging clones, notjust estimating it. Moreover, this technique has an important feature: even if multiple clones are overlapped, thetechnique tries to merge each of them while the existing
research [6] only considers one of the overlapped clones.
Figure 3 shows an overview of the proposed technique.
The input of the technique is a set of source files.
The output is a set of source files in which clones havebeen merged as much as possible and their reducible LoC.
Please note that this technique does not merge clones if
merging them does not reduce LoC of the source files.
The technique is composed of two processes shown below. Both the processes are performed fully automatically.
• Preprocessing source file changes• Clone merging
A. Preprocessing source file changes
First, a new class is generated. The new class is used asa utility class for placing merged clones. More concretely,each merged clone is declared as a static method in
the class. Besides, target source files are edited to avoid
compile error due to improper access modifier of methods
and uninitialized local variables. Additionally, the source
files are reformatted to avoid inconsistencies of reducible
LoC due to coding style. In total, four changes are madein Preprocessing source file changes. We describe each of
the changes in Section IV-A:• generating a new class,• changing access modifier of methods,• initializing local variables, and• reformatting.

Preprocessing
source file changes
Input

Step1:
Detecting clone sets…
Original
source files

CS_1

Editedsource files

Clone Sets
CS_n

CS_2

Step2:
Editing source files

EditidSource files…
50 LoC
decreases

30 LoC
decreases

10 LoC
decreases
Step3:
Compiling and Testing…

Compilation andtest results

No
Terminate?
Yes

Step4:
Selecting

Outputsource files whose all target clones are merged+
reducible LoC

Fig. 3: Overview of proposed technique
B. Clone Merging
Clone merging is composed of four steps shown below.
All of the steps are performed fully automatically.
Step1: detecting clone sets
Step2: editing source files
Step3: compiling and testing edited source files
Step4: selecting edited source files
In Step1, clone sets in the target source files are detected. In Step2, source files are edited to merge one of
the clone sets that were detected in Step1. A method
extracted to merge clones is placed in the Java classdescribed in Subsection III-A. In Step3, the source files
edited in Step2 are compiled and tested to verify theexternal behavior. Hereafter, we call edited source files
which succeed in compiling and testing and whose LoC
gets reduced selectable source files. Step2 and Step3 areperformed on each of the clone sets detected in Step1. In
Step4, the selectable source files whose reduced LoC is
the largest is selected. Then, Step1∼Step4 are repeatedly
performed on the selected source files. When either of thefollowing termination conditions is satisfied, clone merging
terminates and outputs the reducible LoC.
••No clone sets are detected.
No source files edited in Step2 are selectable.

IV. implementation
We implement our technique as a tool. The tool iswritten in Java and targets Java source files.
A. Preprocessing source file changes
Generating a new Java class
A class in which extracted methods are placed is newly
generated. When the extracted method in the new class iscalled from the original place, it is invoked with its fully
qualified name.
Changing access modifier of methods
When a method whose access modifier is not public
is invoked from another class, a compile error occurs. In
manual refactoring, developers can deal with this problem
in various ways when refactoring clones. For example,
developers can change the access modifier of methods
properly, or they can declare the extracted method in
the class in which clones were detected. However, in the
proposed technique, it is diﬃcult to infer which ways
to take because extracting and declaring a method are
performed fully automatically. Therefore, access modifiersof all methods are beforehand changed to public.

1
2
3
4
5
6

if (a > b){
int temp = a;a = b;
b = temp;
}

1
2
3
4
5
6
1

- if (a > b)
- {int temp = a;a = b;
b = temp;- }+ method(a, b);

1
2
3
4
5

if (a > b) {int temp = a;a = b;
b = temp;
}

1
2
3
4
5
1

- if (a > b) {int temp = a;a = b;
b = temp;- }+ method(a, b);projects, but of course, it is impossible. Thus, we use thedefault Eclipse formatter [12].
B. Clone Merging(a) 5 LoC reduce

Step1: Detecting clone sets(b) 4 LoC reduce

Fig. 4: Diﬀerent reducible LoC
BlocksNormalizing

Hashing Comparing
Clonesif (a > b) {int temp = a;a = b;
b = temp;}

if ($0 > $1) {int $2 = $0;$0 = $1;$1 = $2;
}

1234

1234

if (x > y) {int tmp = x;x = y;
y = tmp;}if ($0 > $1) {int $2 = $0;$0 = $1;$1 = $2;
}

1234

1234

...

if ($0 < $1) {int $2 = $1;$1 = $0;$0 = $2;
}

...

...

...

if (i < j) {int tmp = j;j = i;
i = tmp;
}

5678

5678

Fig. 5: Detecting clones
Initializing local variables
On the Java language specification, it is prohibitedto reference uninitialized local variables. Thus, when an
uninitialized local variable is passed to the extracted
method as an argument, a compile error occurs. Developers may initialize local variables and pass them to themethod when developers merge clones. In this study, alllocal variables which do not have final modifier and areuninitialized at the time of their declaration are initialized.
In the case that the local variable is primitive type except
for boolean type, it is initialized as “0”. In the case ofboolean type, it is initialized as “false”. In the case ofreference type, it is initialized with “null”.
Reformatting
In general, coding conventions are specified in eachproject. For example, some conventions specify using manyline breaks and other conventions specify a small numberof line breaks. If code fragments of convention violation
exist, it is diﬃcult to calculate a reducible LoC properly.
Figure 4 shows examples in which diﬀerent reducible LoC
are calculated due to the coding style.
Figure 4a, Extract Method refactoring reduces 5 LoC,
but Figure 4b, Extract Method refactoring reduces 4 LoC.
Thus, it is necessary to unify coding style by using formatter. In an ideal world, we should prepare the formatterswhich reproduce coding conventions of each of the target

Figure 5 shows an example of detecting clones. Clones
are detected in block level. We regard the following statements as blocks. Each following statement is defined as a
derived class of class Statement in Eclipse JDT [13].
• Block• DoStatement• EnhancedForStatement• ForStatement• IfStatement• SwitchStatement• SynchronizedStatement• TryStatement• WhileStatement
Block-level clones are more coarse-grained than clones
that are detected by token-based techniques. The numberof block-level clones is less than the number of token-based
clones. Block-level clones have a remarkable feature, whichis that they are better candidates of Extract Method refactoring because the code fragments are syntactic chunks.
The proposed technique uses Eclipse JDT to parse source
files and identify blocks. If a block includes a returnstatement, it is not detected as a clone because it isdiﬃcult to extract it as a new method [14].
The proposed technique normalizes identified blocks
according to the rules shown below because the larger
number of clones can be detected by applying the rules.
• Identifiers are normalized as “$” + “number”.
• The same identifier is normalized as the same normalized name.
• All literals are normalized as “$”.
• Qualified names are normalized as identifiers.
• Class name is not normalized.
• Method name is not normalized.
The same identifier is normalized as the same normalized name to avoid false detection as much as possible. The
reason why class and method names are not normalized is
to avoid detecting clones whose diﬀerences are class or
method names because classes and methods cannot bepassed to method invocations as arguments in the Java
specification.
After the normalization, a hash value is calculated fromeach block. The proposed method uses SHA256 hashingalgorithm [15]. Since SHA256 outputs 256-bit hash value,hash collisions hardly occur.
Finally, the proposed technique compares the hash values of blocks to detect blocks of the same hash values asclones.
Step2: Editing source files
Using Extract Method refactoring on one of the clone
sets detected in Step1, source files are automaticallyClone Sets
if (a > b) {int temp = a;a = b;
b = temp;}
if (x > y) {int temp = x;x = y;
y = temp;}

Edited CodeReplacing Method Call
Pass by ReferenceA
int[] a0 = {a}; int[] a1 = {b};package.Class.extracted(a0, a1);
a = a0[0]; b = a1[0];All Detected Clone SetsB

int[] a2 = {x}; int[] a3 = {y};package.Class.extracted(a2, a3);
x = a2[0]; y = a3[0];Refactorable Clone Sets
Extracted and Declaredvoid extracted(int[] p0,int[] p1){
if (p0[0] > p1[0]) {int temp = p0[0];p0[0] = p1[0];p1[0] = temp;}}

Fig. 6: Editing source files
edited. Figure 6 shows an example of automatically editing
source files.
It is possible to reduce LoC because each of the clones isreplaced to a method invocation by extracting clones as amethod. This extracted method is declared as a static
method in the class made in Preprocessing source files
changes (see Section IV-A). The method is invoked with
its fully qualified name.
In practice, we need to take care of changes of variables
on Extract Method refactoring. For example, when only
one of the variables is changed in the code fragment,
Extract Method refactoring can be performed by returning
the variable and assigning it in the caller place. However,in the Java language specification, it is impossible toreturn two or more parameters simultaneously. Extract
Method refactoring on such clones is not realistic. Unfortunately, examining whether or not each variable is changedin the target code fragment requires deep source codeanalysis. Thus, In this study, we implemented our tool topass arguments by reference to the extracted method tokeep the external behavior. Our tool uses an array type topass arguments by reference. Before invoking the extracted
method, arrays whose types are the same of variables inthe target code fragment are newly defined and initializedwith each of the values. These arrays are passed to themethod. In the method, the array element at index zero isreferenced. After invoking the method, each array element
at index zero is assigned back to each variable. These
processes are devices of implementation for automatedrefactoring, not for manual refactoring.
Step3: Compiling and testing edited source files
In Step3, source files edited in Step2 are compiled andtested. At first, compilation is performed. After compilation gets success, test runs. If both compilation and test
get success, edited source files are recorded as selectablesource files. If either compilation or test fails, edited source
files are not recorded.
Step4: Selecting edited source files
After Step2 and Step3 are performed on each of theclone sets detected in Step1, Step4 is performed. In Step4,
the selectable source files whose reduced LoC is the largest

Fig. 7: Target clone sets
is selected. Then, Step1∼Step4 are repeatedly performedon the selected source files.
V. Experiment
A. Experimental Design
We apply our technique to open source software (inshort, OSS). Additionally, we compare our technique tothe existing technique [6].
B. Experimental Item1
We investigate how diﬀerent reducible LoC is obtainedin considering refactorability. First, clone sets are detectedfrom the target OSS by using our technique. These clone
sets correspond to A in Figure 7. Then, the existing technique is applied to them, and a reducible LoC is estimated.
Finally, we use our technique to calculate a reducible LoC
from target OSS and compare the two techniques.
C. Experimental Item2
We investigate how diﬀerent reducible LoC is obtainedin considering clone overlapping. First, clone sets aredetected from the target OSS by using our technique.
Second, the source files in the target OSS are edited
to merge each clone set, and compilation and test are
performed. As a result, we obtain refactorable clone sets.
These clone sets correspond to B in Figure 7. Then, theexisting technique is applied to them, and a reducible LoC
is estimated. Finally, we use our technique to calculate
a reducible LoC from target OSS and compare the twotechniques.
The diﬀerence between Item1 and Item2 is the target
clone sets, in Item1, the targets are all detected clone sets
(A in Figure 7) while the targets are only refactorable clone
sets (B in Figure 7) in Item2.
D. Experimental Targets
We experimented on OSS written in Java. Our targets
are composed of jEdit, JFreeChart, JRuby, Ant, andJMeter, which existing research of clone refactoring [16]targets and Closure Compiler (in short, Compiler) and
Joda-time, which Defects4J [17] targets. Defects4J isa collection of reproducible bugs and a supporting infrastructure with the goal of advancing software engineering research. The reason why we add Compiler andJoda-time to the targets is that we think the projects
possess suﬃcient tests. The proposed technique runs tests
to verify the external behavior. Thus, it is to be desiredthat the target projects possess suﬃcient tests to verify

cloneA

the external behavior. The projects targeted in Defects4J
possess tests which can detect the bugs, and we think they
possess suﬃcient tests.
Table I shows the name, version, and total LoC of thetarget projects. We do not target test code and tutorial
code of the targets. We measure the total LoC after we
use the formatter (see Section IV).
E. Results and Discussion of our technique
Table II shows the results of our technique performingon the target projects. We use a personal workstation inthis experiment.
• CPU: 2.40GHz, 12Core• Memory: 32GB
• OS: Ubuntu18.04
As a result, the refactorable and line-reducible clone sets
(Herein, line-reducible clone sets mean that refactoringthem can reduce LoC of the target projects) account for5∼10 percent of the all detected clone sets. The major
causes why compilation or test fails are shown below.
• The types of variables between diﬀerent code fragments in a clone set are diﬀerent.
• There are clones including references to a Superclass.
• Exceptions thrown in the clone fragment are caught
at the outside of the fragment.
• Loop control statements(e.g., break) are used in theclone fragment, but loop statements(e.g., for) areused in the outside of the fragment.
Some clone sets will be refactorable if we devise to
implement our tool. For example, if all code fragments ofa clone set are in a class and the code fragments include
references to a Superclass, extracting the code fragments
as a method in the same class can generate compilable
source code.
F. Results and Discussion of Topic1
Table III shows the results of Experimental Item1. The
existing technique regards the larger number of clone
sets as refactorable than the number of clone sets thatthe proposed technique was actually able to refactor andVersion
5.4.0
1.0.19
1.7.271.10.1
3.2
20190618
2.10.3Fig. 8: Real overlapped clones
estimates more reducible LoC. This is because the existing
technique does not consider the refactorability of the clone
sets and estimates reducible LoC on non-refactorable clone
sets. Thus, if directly the existing technique is applied toclone sets detected by a clone detection tool, it estimates
more reducible LoC than actual and the value is improper.
G. Results and Discussion of Topic2
Table IV shows the results of Experimental Item2. The
number of clone sets that the proposed technique merges
and the reducible LoC that the technique calculated isequal to or greater than the existing technique. This isbecause when overlapped clone sets are detected, the existing technique merges the most line-reducible clones andignores the others while the proposed technique merges
the most line-reducible clone sets, detects clone sets again,
and merges the other overlapped clone sets if they are linereducible. Figure 8 shows examples of such clone sets. Bothclone A and B are detected in jEdit. Clone A includes B.
Clone A is 20-LoC, and the clone set consists of 2-clones.
Thus, 16-LoC can be reduced when they are merged. On
the other hand, B is 5-LoC, and the clone set consistsof 6-clones. Thus, 17-LoC can be reduced when they are
merged. In this case, the existing technique targets theclone set of clone B and ignores A. However, at first,
the proposed technique merges the clone set of clone B.
TABLE III: Results of Topic1

jEdit
JFreeChart
JRuby
Ant
JMeterCompiler
Joda-Time

Total KLoC
163
236
334
231
79
250
74

cloneBfor(int col = fromCol; col = toCol; col++){int minimumColWidth = minimumColWidths[col];if((Integer.MAX_VALUE - minimumColWidth) < currentMinimumColWidth) {currentMinumumColWidth = Integer.MAX_VALUE;} else {currentMinimumColWidth += minimumColWidth;}
int preferredColWidth = preferredColWidths[col];if((Integer.MAX_VALUE - preferredColWidth) < currentPreferredColWidth) {currentPreferredColWidth = Integer.MAX_VALUE;} else {currentPreferredColWidth += prefferedColWidth;}
int maximumColWidth = maximumColWidths[col]if((Integer.MAX_VALUE - maximumColWidth) < currentMaximumColWidth) {currentMaximumColWidth = Integer.MAX_VALUE;} else {currentMaximumColWidth += maximumColWidth;
}
}

Name

TABLE I: Target OSS
Name
jEdit
JFreeChart
JRuby
Ant
JMeterCompiler
Joda-Time

814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833

Existing technique#Merged
Reducible
CS
LoC
237
2115
462
5168
519
4201
371
3633
49
291
179
1599
23
171

Proposed technique#Merged
Reducible
CS
LoC
57
534
145
1104
236
1281
7
327
5
21
27
183
9
61

TABLE IV: Results of Topic2
TABLE II: Results of our technique
Name
jEdit
JFreeChart
JRuby
Ant
JMeterCompiler
Joda-Time#Detected
CS
423
848
858
635
114
286
89

#Merged
CS
57
145
236
7
5
27
9

Reducible
LoC
534
1104
1281
327
21
183
61

Execution
Time
40m
2h48m
6h4m
20m
3m
3h13m
7m

Name
jEdit
JFreeChart
JRuby
Ant
JMeterCompiler
Joda-Time

Existing technique#Merged
Reducible
CS
LoC
55
517
142
1098
231
1270
7
327
5
21
27
183
9
61

Proposed technique#Merged
Reducible
CS
LoC
57
535
145
1104
236
1281
7
327
5
21
27
183
9
61

Then our technique detects clone sets, and the clone setof cloneA whose code fragments of cloneB is replaced toa method invocation is detected. Thus, our technique cantarget the clone set of clone A and calculate a reducible
LoC by merging both clone sets.
The results of Subsection V-F and Subsection V-G, we
can say that our technique can calculate reducible LoC ofprojects more accurately than the existing technique.
VI. Threats to validity
We experimented on seven OSS. However, if experiments are done on other projects, the results may be
diﬀerent from this study.
In java, method declarations consist of method bodyand an additional 2-line code. The additional code is composed of a method signature line and a close bracket line.
However, other programming languages are not always
fitted this rule. Therefore, such languages require diﬀerent
formulas of reducible LoC, and the result may be diﬀerent
from this study.
We implemented the proposed technique as a tool, butsome of the implementations are still insuﬃcient. If we
improve our implementation, the more correct reducible
LoC calculation can be expected.
Existing research proposes not only Heuristic Method
but also Complete Method to estimate reducible LoC. In
Complete Method, each clone is divided into multiple codefragments, each of which includes no partial overlapping
fragment with any other clones. Complete Method is designed to aim at merging and removing all clones. However, the possibility of dividing clones is not consideredin Complete Method. For example, when a code fragment
is divided into two code fragments, and each of them is
extracted as a method, the latter method cannot reference
variables declared in the former method. Existing research
explains that Complete Method gives an upper bound of
the reducible LoC and do not care about the feasibility
and usefulness of this merging in practice. Thus, we did
not compare our proposed technique to Complete method.
VII. Conclusion
In this paper, we proposed a new technique to calculatelines of code that are reduced by removing clones. The
proposed technique performs a loop of detecting clones,
removing clones, compiling the edited source code, andtesting it fully automatically. Thus, the proposed technique calculates reducible lines of code from only clones
that actually can be removed while an existing techniqueestimates it without considering refactorability of clones.
The followings are our future work.
Utilizing other refactoring patterns
At this moment, the proposed technique utilizes Extract
Method pattern to remove clones. However, there are various ways to remove clones: for example, Pull Up Method
or Form Template Method. Considering other refactoring

patterns to remove clones, calculated reducible LoC will
get closer to the real value when developers appropriately
remove clones.
Avoiding compilation errors
As described in Section V, we encountered many compilation errors in the experiment. However, most of suchcompilation errors are avoidable if we devise an implementation. If we do so, we will be able to get better reducible
LoC.
Acknowledgment
This work was supported by MEXT/JSPS KAKENHI
17H01725.
References[1] B. P. Lientz and E. B. Swanson, Software Maintenance Management. Addison-Wesley Longman Publishing Co., Inc., 1980.
[2] S. G. Eick, T. L. Graves, A. F. Karr, J. 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.
[3] T. M. Pigoski, Practical Software Maintenance: Best Practices
for Managing Your Software Investment, 1st ed. Wiley Publishing, 1996.
[4] H. M. Sneed, “Planning the reengineering of legacy systems,”
IEEE Software, vol. 12, no. 1, pp. 24–34, Jan 1995.
[5] M. Fowler, Refactoring: Improving the Design of Existing Code,ser. Addison-Wesley Signature Series.
Pearson Education,
1999.
[6] N. Yoshida, T. Ishizu, B. Edwards, III, and K. Inoue, “HowSlim Will My System Be?: Estimating Refactored Code Sizeby Merging Clones,” in Proceedings of the 26th Conference on
Program Comprehension, 2018, pp. 352–360.
[7] 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.
[8] Y. Higo, S. Matsumoto, S. Kusumoto, T. Fujinami, andT. Hoshino, “Correlation Analysis between Code Clone Metrics
and Project Data on the Same Specification Projects,” in Proc.
of the 12th International Workshop on Software Clones, 2018,
pp. 37–43.
[9] L. Jiang, G. Misherghi, Z. Su, and S. Glondu, “DECKARD:
Scalable and Accurate Tree-Based Detection of Code Clones,”
in Proceedings of the 29th International Conference on Software
Engineering, 2007, pp. 96–105.
[10] J. R. Cordy and C. K. Roy, “The NiCad Clone Detector,” in2011 IEEE 19th International Conference on Program Comprehension, 2011, pp. 219–220.
[11] “CCFinderX,” http://www.ccfinder.net/.
[12] “Eclipse,” https://www.eclipse.org/.
[13] “Eclipse java development tools,” https://www.eclipse.org/jdt/.
[14] R. Komondoor and S. Horwitz, “Eﬀective, automatic procedure
extraction,” in 11th IEEE International Workshop on Program
Comprehension, 2003, pp. 33–42.
[15] National Institute of Standards and Technology, “Secure Hash
Standard,” 2015.
[16] N. Tsantalis, D. Mazinanian, and S. Rostami, “Clone Refactoring with Lambda Expressions,” in Proceedings of the 39th
International Conference on Software Engineering, 2017, pp.
60–70.
[17] R. Just, D. Jalali, and M. D. Ernst, “Defects4J: A Database of
Existing Faults to Enable Controlled Testing Studies for Java
Programs,” in Proceedings of the 2014 International Symposium
on Software Testing and Analysis, 2014, pp. 437–440.