Evolution of Code Clone Ratios throughout
Development History of Open-Source C and C++
Programs
Anfernee Goon∗ , Yuhao Wu† , Makoto Matsushita† , and Katsuro Inoue†∗ Department of Computer Science and Engineering, University of California San Diego

La Jolla, United States of America
agoon@ucsd.edu† Graduate School of Information Science and Technology, Osaka University
Osaka, Japan{wuyuhao, matusita, inoue}@ist.osaka-u.ac.jp

Abstract—A code clone is a fragment of code which is duplicated throughout the source code of a project. Code clones havebeen shown to make a project less maintainable because all code
clones will share potential bugs and problems. Unlike other code
clone research, this study analyzes the code clone ratios over theentire development lifetime of three open-source projects written
in C/C++ to understand code clone growth in software overdevelopment and potential developer habits which could affectthis growth. The study utilizes CCFinderX and Git to detect clone
metrics across development history. The results from each projectshow very low, stable ratios across development history, with thecode clone ratios only fluctuating greatly during the beginningof development mostly and very little refactoring occurring. This
study goes further into the potential cause of low ratios anddifferent fluctuations at different periods of development.
Index Terms—code clone ratio, refactoring, code clone maintenance, open source software

RQ1. What patterns can be observed of code clone growth
based on the ratios gathered from each project?
• RQ2. How do the code clone ratios throughout
development characterize code clone maintenancehabits?.

•By analyzing code clone growth within developing software,
it is possible to better understand the developer’s efforts in code
clone maintenance, specifically efforts in refactoring. Although
the general consensus is that code clones make software lessmaintainable and propagate bugs, some studies have shown thatsome clones can actually be beneficial [2]. By understanding
the effectiveness of certain code clone maintenance techniques,
it will be more clear what research needs to be done to increase
the effectiveness of code clone maintenance.

I. I NTRODUCTION

II. A PPROACH
A code clone is a duplicated fragment of code. Having
A. Target Source Dataset
many code clones in a project makes it much less maintainable
When deciding on open-source projects to use, we took
because all of these code clones will share potential bugs andproblems [1]. These problems will propagate throughout the into account a couple factors. These factors were how wellsoftware with continued use of the problematic code clone studied the project is, how large the project is, and the typefragment, and a fix for this bug may have to be applied to every of the project itself. We wanted to use three projects which
one of these fragments present in the code. Detecting code varied by these metrics in order to analyze the effects of theseclones and retrieving code clone metrics for a target software factors on the code clone ratios and what they imply about
can aid in bug fixing and general code clone maintenance of the development process. We analyzed the following threeopen-source projects which are hosted on GitHub:
the detected clones.
An abundance of code clone research focuses on the code1) libcurl: libcurl is a library which curl, a command-line
clone metrics of software at one particular snapshot. Insteadof focusing on a specific point in time, we analyze the tool for transferring data, uses. This library is fairly well studied
code clone metrics of software over the entire development as seen in Kawamitsu et al. [3]. It is the smallest project weprocess. In this paper, we seek to understand code clone studied, starting at around 2,500 lines of code, eventually
growth and maintenance through the analysis of code clone growing to around 12,500 lines of code over a series of about
metrics throughout the entire development process of three 20,000 commits.
different open source projects primarily written in C/C++.
2) Skynet: Skynet is a lightweight online game framework
More specifically, we will investigate the following research which is slightly larger than libcurl, growing from around 2,500
questions in our analysis:lines of code to around 40,000 lines of code over a series ofabout 1,000 commits (we analyze about 800 of those commits).

978-1-5090-6595-0/17/$31.00 c 2017 IEEE

47

IWSC 2017, Klagenfurt, Austria

TABLE I
D ESCRIPTION OF M ETRICS U SED
MetricDescription

LOC

Total lines of code, given by CCFinderX

SLOC

Total lines of code not including whitespace or comments, given by CCFinderX

CLOC

Total code clone lines, given by CCFinderX

CCR

Ratio of code clone lines to total lines of code, or CLOC divided by LOC

SCCR

Ratio of code clone lines to total lines of code not including whitespace or comments, or CLOC divided by SLOC

While not as well studied as the other two projects, it is as
popular as libcurl on Github based on forks and stars.
3) Git: Git is a version control system which is widely used;even our analysis relies on Git. Although starting relatively
small at 950 lines of code, it grows to around 200,000 lines
of code over a series of about 40,000 commits (we analyze
about 14,000 of those commits) which is significantly larger
than both libcurl and Skynet.
Each of the three open-source projects present a different
range in size which may provide valuable information onwhether size affects code clone growth. Having software whichis popular in use and analysis lessens the chance of abnormal
data coming from one of the projects. The varying functionsof each project ensure that the analysis covers the developmentof various types of software.

of the program Gemini [5]. GemX’s biggest asset is it’s ability
to show the clone pairs found in the source code. Using thistool, we were able to analyze a big increase or decrease in
SCCR and see what caused to fluctuation. This was done by
first running GemX on the commit previous to the fluctuationin SCCR and noting what clone pairs existed at that point. We
then ran GemX on the commit which caused the fluctuation,and looked at whether the clone pairs that existed previously
still remained, or if they were refactored out of the code base.
III. R ESULTS

B. Clone Detection
To detect clones and clone metrics in the source code, weused CCFinderX, a token-based clone detector [4] [1]. Although
CCFinderX is a multilinguistic clone detector, we only use it’s
C/C++ clone detection capabilities. Using bash scripting, we
automated the use of CCFinderX on every important commit
in the master branch of each project by using git log withthe –first-parent flag. The commits retrieved with this flag areimportant because they represent the most linear development
history available by following the first parent down Git’s
history ensuring that parallel development on separate branches
are limited to the merge commit into master. Similarly, we
automate the retrieval of clone metrics from CCFinderX’s
results to streamline collecting the results from each commit.
For each commit, we collected number of C/C++ files, themetrics found in Table 1, as well as the tag of the commit
if applicable. The scripts were designed to exclude test andexample files whenever possible in order to keep analysis
limited to functionality related files, and only includes .c and.cpp files. Header files are not included because most header
files are naturally similar to each other, and may be pickedup as false positives by CCFinderX. The minimum number oftokens that a fragment needs to be considered a clone is 50 inour study.
C. Qualitative Approach
Our qualitative approach to analyzing each project utilizes
a tool called GemX, which provides GUI options along with
CCFinderX’s normal clone detection. It is an improved version

48

For our quantitative analysis, we make use of several graphs
containing the metrics SCCR, SLOC, and CLOC discussed in
Section 2.2 displayed by commits in chronological order. The
main metric we focus on is SCCR, which we initially expected
to have mostly gradual increases with periodic sharp declines.
The gradual increases would be a result of functionality being
added over time, which naturally increases SCCR because morecode is being written [6]. Refactoring would be the cause of
the sharp declines, because the initial additions of functionality
may not be clean and would be in need for maintenance toensure maintainability before the next round of functionality isadded. The results from all three projects did not quite follow
this trend, and in fact all projects displayed various different
patterns over development.
A. libcurl
Our analysis of libcurl is confined to the files in libcurl’s
src folder in addition to the test and example constraints
previously mentioned. The src folder is the primary folder for
development for libcurl’s C/C++ modules, so it contains themost relevant information about libcurl’s development process.
1) Quantitative Analysis: Fig. 1 is libcurl’s clone metrics
graph, detailing a series of sharp increases followed by gradualdecreases in SCCR which is the opposite of expectation.
In hindsight, this finding makes sense because the numberof consecutive commits which add functionality will besignificantly less than the total number of commits resulting
in sharp increases in SCCR on the graph when functionality
is added. Although decreases are still occurring, the gradualnature of these decreases indicates that refactoring is notnecessarily the cause. From a perspective focused on clones,
refactoring would be indicated by a decrease in CLOC and
SLOC, because this means that code clone fragments are being
removed. Looking at the SLOC and CLOC metrics during these

SCCR (Left Axis)
Tag SCCR (Left Axis)
SLOC (Right Axis)
CLOC (Right Axis)●●● ●● ● ●●●●●●● ● ●●
●

●●
●●

● ● ●

●●

●

●
●
●
●●

●● ●

●

●
●●

●
●

● ●●●●●

●

6

● ●●

2000

8

●

●

●
●●

●
●
●●
●
●
●●
●●●●
●●
●●

● ●
●

●
●●

●

●●

● ●●
●
●●

● ●

●

●
●

●●

●

●

●
●● ● ●

●
●●●●

●

● ●●
● ●

● ●●
●

Lines of Code

4000

12
10

Percentage

14

6000

16

●

8000

18

libcurl Clone Metrics Graph

●
●

●● ●

●●●
●●

●●

●●
●

0

4

●●
●●
●●
●
●
●●
●●

0

5000

10000

15000

20000

Chronological Commit Number

Fig. 1. SCCR, SLOC, and CLOC changes over all commits of libcurl in chronological order.

periods of decrease, we observe that the SLOC is continually
increasing while the CLOC does not decrease. Since SCCR
is a ratio between CLOC and SLOC, it is clear that it is thegrowth in SLOC which is causing the decreases and not a
result of refactoring.

commit hashes). On the clone metrics graph, each of thesecommits represent a point before a rise or fall.

The first two commits saw a SCCR decrease of about 2% anda CLOC decrease of about 30 lines. In both these instances,the logic of the clone fragments were changed with a few
While this trend holds true for the majority of libcurl’s additions or deletions. These fragments can still be considereddevelopment, the beginning of libcurl’s development does code clones, but are now Type-3 code clones instead of Type-2
have some sharper decreases which are a result of CLOC code clones, where Type-3 clones have some line additions
decreasing. These decreases are not due to refactoring, which and deletions which do not occur in the other fragment [1].
is discussed in more detail in the next section. Contrary to Since CCFinderX cannot detect Type-3 code clones, this was
the sharp increases depicted on the SCCR graph, the SCCR seen as a decrease in CLOC resulting in the SCCR decreases
is actually quite stable with the sharp increases actually only [1]. It is clear that the decreases were not due to refactoring
being about a 1% difference. Throughout the entire lifetime of in this case, but rather something more akin to a bug fix todevelopment, the SCCR mostly falls between 3% and 9%. make the fragments work correctly by changing a few parts of
The stable, low SCCR of libcurl throughout development the fragments (and even still the fragments are Type-3 clones).
may indicate a good development habit of refactoring before This case illustrates the importance of also looking at thecommits. This practice ensures a more stable clone rate with change in SLOC to determine if refactoring occurred, because
less clones being introduced each commit, leading to a cleaner if SLOC also decreases by a similar margin then there is a
git history and consistent maintainability. Unfortunately we good chance the clone was removed. This phenomenon ofcannot confirm this technique is in fact in use as we are only clones becoming undetectable due to change in type is a threat
analyzing code that has been committed. Although libcurl does to validity discussed in Section 3.5.
have relative stability throughout its development, it is still
Unlike the first two commits, the last two commits show theconsistently growing especially towards the end of development,
most refactoring seen in libcurl. The first of the two commits,
where a 1,000 commit sequence adds about 2% to the SCCR.
b5fdbe8, shows a huge increase in CLOC (from around 4%2) Qualitative Analysis: For libcurl’s qualitative analysis, to around 18%) while the other commit, a0d7a26, shows a
we studied key rises and falls on the SCCR graph attributed to symmetrical decrease (from around 18% to around 4% again).
CLOC changes in further depth using the qualitative approach The first commit adds a new experimental functionality throughdescribed above. There are four commit points which are looked a new file which is an exact copy of another source file thatat in libcurl: 6562caf, 22d8aa3, b5fdbe8, a0d7a26 (shortened is about 600 lines, increasing the CLOC by that margin. The

49

20000
●

●

●

●

●

●
●

●

●

●

● ●

●
●●
●●● ●
●
●
●●●● ●●
●●
●
●●

0

2

5000

●●
●●

●

10000

4

● ● ●

15000

6
Percentage●●●

Lines of Code

25000

SCCR (Left Axis)
Tag SCCR (Left Axis)
SLOC (Right Axis)
CLOC (Right Axis)

8

●

30000

Skynet Clone Metrics Graph

0

200

400

600

800

Chronological Commit Number

Fig. 2. SCCR, SLOC, and CLOC changes over all commits of Skynet in chronological order.

second commit significantly changes the new source file to which occur only a few times throughout the entire commit
reuse parts of the original source file along with new features, history. The unexpected differences are the sharp increases
this eliminating the entire clone fragment as it was in the which mirror the sharp declines, as well as the extreme stability
previous commit and reducing the CLOC down once more. which characterizes the second half of the development history.
This shows the only clear case of refactoring we have found Similar to libcurl, Skynet’s SCCR graph’s sharp increases
libcurl, with the developer implementing reuse of source files most likely indicate an addition in functionality. These only
indirectly rather than keeping directly copied pasted code.
occur during the first half of development, but are considerable
Observation 1 - Overall, libcurl’s SCCR fluctuations display increases, with the largest increase going from 6% to aroundopposite trends to our original expectations. The SLOC and 9%. The mirrored sharp decreases may indicate refactoring after
SCCR follows a general trend of increase occurring mostly with large functionality additions. Most of these sharp decreases
sharp increases over a small number of commits, but there have corresponding CLOC decreases, but only a few haveare gradual decreases among the fluctuations. Our manual corresponding SLOC decreases as well indicating refactoring
analysis shows that code refactoring is not the cause of most is not necessarily the case for every instance. The qualitative
decreases but rather from a lack of CLOC increase. Even analysis of Skynet in the next section confirms refactoring
without refactoring, SCCR is still very low indicating that efforts, showing that refactoring does occur in some of these
refactoring may be occurring before commits or that the instances.
developers are simply able to write good code with a low
Although the development of Skynet has fairly sharp
amount of clones.
fluctuations during the beginning of its development, it actuallyshows greater stability than libcurl after its initial fluctuations,
B. Skynet
occurring directly after the first release. The stability after
Unlike libcurl’s analysis, our analysis of Skynet takes
release seems to be logical, as a polished product should
account all C/C++ files that the project contains excluding files
be delivered at release, reducing the additions to mostly
in the test folder. There was no single folder consolidating all
bug fixes which are less likely to introduce new clone additions.
of Skynet’s C/C++ modules, so analyzing all the files in the
project was a necessity.
2) Qualitative Analysis: Skynet’s qualitative analysis used
1) Quantitative Analysis: Skynet’s clone metrics graph, the same approach as libcurl’s, where we looked at big
shown in Fig. 2, shows SCCR fluctuations that partially fluctuations on the SCCR graph that resulted from CLOC
resemble what was initially expected, but with some significant changes in detail using GemX. The main commits that we
differences. The resemblance is in the graph’s sharp declines, looked at in Skynet are 28dc840 and 58aa755. Again as in

50

●

●
●
●
●
●

●
●
●

8

SCCR (Left Axis)
Tag SCCR (Left Axis)
SLOC (Right Axis)
CLOC (Right Axis)

●

●
●
●
●
●

●

●

●
●

●
● ●
●● ●
●
● ●
●●●
●●
●●●●●●
●

●●
●
●

●

100000

●
●

●

●
●
●
●

●
●
●
●
●●●

●

6

●
●
●
●

●
●
●
● ●
●
●
●
●
●
●
●
●●●

●●
●
●

●
●●
●
●
●●
●
●

●
●
●

●
●
●●
●
●
●
●

●
●
●
●
●
●

● ●
●●
●
●
●●
●
● ●
●
●
●

●
●●
●
●
●
● ●
●
●●
●

●
●
●

●
●
●
●

●
●
●

●
●
●●
●
● ●
●
●
● ●
●
● ●
●
●●
●
●●
●
● ●
●
● ●
●
●

● ●
●
●
●
●
●

0

2

4

●
●

50000

●●
● ●●●
●
●
●
●●
●
●
●
●
●
●

Lines of Code

●
●
●
●

Percentage

15000010

Git Clone Metrics Graph

0

5000

10000

15000

Chronological Commit Number

Fig. 3. SCCR, SLOC, and CLOC changes over all commits of Git in chronological order.

libcurl, these commits represent a point before a rise or fallon the clone metrics graph.

were shown during this time although this is not provable
unless source code prior to commits is available for analysis.

The two commits show decreases in SCCR of about 1%
and 2% respectively. The cause of these decreases can bothbe attributed to changes in libraries which Skynet was using.
The first commit sees a removal of a part of a library whichcontains 7,000 lines of code, 500 of those being clone lines.
Although not a refactoring of their own modules, this libraryremoval is in fact an instance of refactoring because it removes
unnecessary code, potentially opting for reuse like in libcurl’s
instance of refactoring which in turn reduces CLOC. The
second commit adds on a large library of code to the project
which proportionally has very little code. Through this addition,
the CLOC only increases slightly, by about 260 lines, while
the SLOC increases significantly, by about 10,000 lines. Unlike
the first commit, this is not a result of refactoring as none ofthe originally existing clone pairs were removed.

C. GitSimilar to the analysis of Skynet, our analysis of Git takes
into account all C/C++ files that the project contains excluding
test and example files. Git’s C/C++ modules were dispersed
all throughout the project which is why all files in the projectneeded to be analyzed. Unfortunately all analysis of Git wasdone quantitatively, as a qualitative analysis was difficult
given the size of the project. We hope to perform a qualitative
analysis on Git in the future to reinforce our quantitative
analysis.

1) Quantitative Analysis: The results of Git’s SCCR analysis
is shown in Fig. 3 and follows a similar trend as Skynet. Unlike
our initial expectation, Git’s SCCR sees a large growth towards
the beginning of development, but after a certain point sees
Observation 2 - The fluctuations in Skynet’s SCCR during a gradual but consistent decrease up to the present state of
the beginning of development display similarity to the original development. After its large growth over around 2,000 commits,
hypothesis, but fluctuations become less significant and frequent the SCCR is around 9%. The gradual decrease sees the SCCR
during the later stages of development, showing that instability decrease to 4% over the course of about 8,000 commits, andoccurs at the start of development. Upon qualitative code afterwards there is stability near 4% until the present state
analysis, it is evident that refactoring efforts on libraries are the of development. Like in Skynet, the initial growth can because of most sharp decreases in SCCR. A lack of growth in attributed to many additions of functionality at the beginning
code during the second half of development indicate that most of development. After that initial stage, the CLOC barely
functionality was added during the beginning of development. increases while the SLOC continues to grow at a fast rate,
If this is the case, it is unlikely that Skynet’s developers which is what causes the gradual decline in SCCR, which
employ refactoring before commits because the beginning of indicates functionality is still being added unlike in Skynet’s
development would be more stable and cases of refactoring stable period. The gradual decrease may be due to better code51

being written or code being refactored before being committed, amount of code clones added due to difficulty in refactoring or
thus having the SCCR shrink and the CLOC grow only to a simple neglect of code clone maintenance due to functionality
maintain the 4% SCCR during the stability period.
concerns. If software design is not the issue, the frequency
Unlike in Skynet, the first release does not correspond to of refactoring itself could be a large factor. Looking at thethe beginning of the gradual decrease, but happens during the clone ratios over development history can show how often
large growth period. Despite this, the SCCR is still very low. refactoring occurs and whether this frequency is enough toThis may simply be due to good developer habits, such as code keep the software maintained. Although ideally refactoring
being refactored before being committed as we have mentioned occurs before commits and a SCCR graph similar to the stable
about libcurl. As stated before, we did not do a qualitative part of Git’s graph is produced, time constraints may notanalysis on Git, but we reserve the right to look into this in allow for such intense refactoring practices, which is where
the future. Despite this, the quantitative data still provides us understanding how frequently refactoring should occur can bewith the ability to characterize the development of Git with vital to a project’s code clone maintenance.
the help of the analyses on libcurl and Skynet.
V. T HREATS TO VALIDITY
Observation 3 - The SCCR of Git exhibits a trend ofSince our analysis relies heavily on the output of CCFindincrease during the beginning of development and a gradualtrend of decrease thereafter, implying that the early development erX, it’s limitations pose a threat to our data. CCFinderX’s
stages are more volatile than the rest of development. The inability to detect Type-3 clones could possibly allow for a
extremely low average SCCR suggests refactoring before misinterpretation of the SCCR graph to see more refactoring
commits, but a qualitative analysis is needed to confirm this than actually occurred. This would mostly affect our analysis
of Git because we did not have the time to qualitatively analyze
notion.
it and could not confirm notions on refactoring efforts. The
IV. D ISCUSSION
other two projects saw thorough analysis of pivotal commit
Based on the SCCR graphs of each open-source project, points which may have had this problem. Despite this, the data
it is clear that every project will most likely follow it’s we gathered should still hold weight because there were not
own trends. In spite of this, there is a very broad trend many refactoring points to consider in the first place, especiallywhich is apparent from the results for each project. All three in Git. As mentioned earlier carefully analyzing the SLOC
projects have an initial period of instability and fluctuations, changes could still help distinguish these occurrences. Since
followed by a period of stability. This overall trend suggests a our data can still potentially distinguish these occurrences andgeneral workflow of code clone maintenance. The beginning there are a means of confirming such suspicions, CCFinderX’sof development has a lot of fluctuations because by nature not limitations on detecting Type-3 clones should not be an issue.
everything is very concrete and many large design choices are It should be noted that conducting a similar analysis again
most likely being made or still in discussion. As a result of may benefit from the use of a clone detector which can detect
this, SCCR will change as design choices are made since code Type-3 clones to mitigate the issue completely.
Although mostly being composed of C/C++ files, eachwill need to be changed or refactored to accommodate for new
design choices and general code clone maintenance may be project did contain files of significance to development frominitially neglected to focus on functionality implementation different languages, which could mean that development withalone. Once design has been established, the period of stability different languages could be occurring simultaneously, making
begins where additions to the project can be refactored easily certain periods more stable because functionality is being added
beforehand to fit with certain design principles, reducing the through different undetected means. Since all projects had incode clones added with each commit. While the period of fact a majority of C/C++ files, this issue should not be very
stability may differ depending on what kind of development prevalent as the developers should be more likely to continue
occurs after the design principles are established, these periods development in the language used most frequently for ease ofare still mostly stable. For example, libcurl is still developing compatibility.
on functionality, which results in a gradual increase during
Due to the differing organization structures of each project,
the period of stability. Meanwhile, Skynet has stopped major we were not able to exclude libraries in our analysis indevelopment of functionality resulting in an almost completely every project analyzed. Depending on the project, this could
stable SCCR.
drastically change the clone ratios. Whether the libraries should
Developers can analyze their own projects in similar fashion or should not be included are up for debate, as they still doin order to understand their own software’s code clone growth serve a purpose in development, but are not necessarily written
and how certain maintenance techniques affect this growth. by the developer themselves. Along with this, our analysis
Looking at instability periods of code clone growth and only cover 3 different projects which in hindsight seem to beanalyzing what code clone maintenance techniques were very well developed based on their relatively low clone ratios.
employed during these times can help the developer understand In order to fully understand the anomaly which is software
the effectiveness of these techniques, and make inquiries on why development, an analysis of code clone ratios over the version
these techniques may not have been effective at the time. As evolution of more projects is necessary, in particular projects
mentioned before, changing design choices could increase the which have higher clone rates than our three. This will help us52

distinguish different development patterns as well as understandexactly how libraries affect clone ratios.

to determine the role which code clone refactoring played
during development, as well as make inferences on code
clone maintenance techniques. Each project displayed very
VI. R ELATED W ORK
different short term trends, but overall all projects showed a
Software clones has been a very popular topic of research in period of instability followed by a period of relative stability
recent years, and many different studies have reported findings which may be attributed to project design not being concrete
about code clone ratios as well as the effect of clones on during the initial phase of development. Similar analysis of asoftware maintainability. Koshchke et al. report an average developer’s own software can help the developer understand theclone rate of 12% for open-source C and C++ programs [7]. effectiveness of their code clone maintenance. From there, theThe average clone rate has been reported differently among developer can adjust their code clone maintenance techniques
different studies, with Zibran et al. reporting a clone rate in order to better control code clone growth in their software.
between 9% and 17% for programs written in C, C#, and
ACKNOWLEDGMENT
Java [8]. Chen et al. reports a range of 4.6% and 24.9% whenThis work was supported by Japan Society for the Proanalyzing open-source games written in C, Java, and Python[9]. Clearly ratios differ among studies for different reasons, motion of Science, Grant-in-Aid for Scientific Research (S)including the clone detection tool used, the languages that the JP25220003, and also by Osaka University Program foranalyzed software is written in, and the type of software which Promoting International Joint Research.
was analyzed. More research needs to be done to understandR EFERENCES
what these different metrics indicate about the presence ofA.
Sheneamer
andJ.
Kalita,“Article: A survey of software clone detection[1]clone ratios in software.
techniques,” International Journal of Computer Applications, vol. 137,
As stated previously, the general consensus is that code
no. 10, pp. 1–21, March 2016.
clones can be harmful to software development due to main- [2] C. J. Kapser and M. W. Godfrey, ““cloning considered harmful”
considered harmful: patterns of cloning in software,” Empirical Software
tainability problems and bug propagation, and this is theEngineering, vol. 13, no. 6, p. 645, 2008. [Online]. Available:
assumption used when qualitatively analyzing each of the three
http://dx.doi.org/10.1007/s10664-008-9076-6
projects in this study. Juergens et al. observed software faults[3] N. Kawamitsu, T. Ishio, T. Kanda, R. G. Kula, C. D. Roover, and K. Inoue,“Identifying source code reuse across repositories using lcs-based source
being induced from cloned code in various commercial andcode similarity,” in Source Code Analysis and Manipulation (SCAM),
open-source programs [10]. Lague et al. looked specifically
2014 IEEE 14th International Working Conference on, Sept 2014, pp.
at a large telecommunication system and found several cases
305–314.
[4] T. Kamiya, “Ccfinderx,” http://www.ccfinder.net/.
where cloned code has propagated to software bugs which[5] Y. Ueda, Y. Higo, T. Kamiya, S. Kusumoto, and K. Inoue, “Gemini:the customer had experienced, and has proposed methods to
Code clone analysis tool,” in Proceedings 1st International Symposium
prevent these faults from reaching the customers [11]. Lozano
on Empirical Software Engineering, vol. 2, 2002, pp. 31–32.
[6] M. Dagenais, E. Merlo, B. Laguë, and D. Proulx, “Clones occurence
et al. analyzed method changeability with clones present, andin large object oriented software packages,” in Proceedings of thereported higher costs in changing methods with code clones
1998 Conference of the Centre for Advanced Studies on Collaborative
present [12]. Although several studies have shown detriments
Research, ser. CASCON ’98. IBM Press, 1998, pp. 10–. [Online].
Available: http://dl.acm.org/citation.cfm?id=783160.783170
that come with the presence of code clones, some studies have[7] R. Koschke and S. Bazrafshan, “Software-clone rates in open-source
observed that code clones can actually be beneficial to software,
programs written in c or c++,” in 2016 IEEE 23rd Internationalwith Kapser et al. describing several benefits such as preventing
Conference on Software Analysis, Evolution, and Reengineering (SANER),
vol. 3, March 2016, pp. 1–7.
instabilities in code through the use of code clones to introduce[8] M. F. Zibran, R. K. Saha, M. Asaduzzaman, and C. K. Roy, “Analyzing
new features [2]. They also report that as many as 71% ofand forecasting near-miss clones in evolving software: An empiricalclones have a positive impact on software maintainability. With
study,” in 2011 16th IEEE International Conference on Engineering ofComplex Computer Systems, April 2011, pp. 295–304.
the ongoing debate about how code clones actually effect[9] Y. Chen, I. Keivanloo, and C. K. Roy, “Near-miss software clones insoftware maintainability, it is important that further research isopen source games: An empirical study,” in 2014 IEEE 27th Canadiandone to truly understand what harms or benefits cloned code
Conference on Electrical and Computer Engineering (CCECE), May
2014, pp. 1–7.
can have on software to allow proper qualitative analysis of[10] E. Juergens, F. Deissenboeck, B. Hummel, and S. Wagner, “Do code
clones and to develop efficient software maintenance practices
clones matter?” in Proceedings of the 31st International Conference
which make use of clone awareness [2].
on Software Engineering, ser. ICSE ’09. Washington, DC, USA:
VII. C ONCLUSION
In this paper, we analyzed code clone ratios over theversion evolution of three very different open-source projects.
Our analysis primarily focused on the SCCR throughout
version evolution in conjunction with the SLOC and CLOC
at each particular commit point to understand different partsof the development process. With this data it was possible

53

IEEE Computer Society, 2009, pp. 485–495. [Online]. Available:
http://dx.doi.org/10.1109/ICSE.2009.5070547[11] B. Lague, D. Proulx, J. Mayrand, E. M. Merlo, and J. Hudepohl,“Assessing the benefits of incorporating function clone detection in adevelopment process,” in 1997 Proceedings International Conference on
Software Maintenance, Oct 1997, pp. 314–321.
[12] A. Lozano and M. Wermelinger, “Assessing the effect of clones onchangeability,” in 2008 IEEE International Conference on Software
Maintenance, Sept 2008, pp. 227–236.