Finding repeated strings in code repositories and its
applications to code-clone detection
Yoriyuki Yamagata∗ , Fabien Hervé† , Yuji Fujiwara∗‡ Katsuro Inoue∗‡∗ National Institute of Advanced Science and Technology (AIST)

Email: yoriyuki.yamagata@aist.go.jp† University of Nantes
Email: fabien.herve1@etu.univ-nantes.fr‡ Osaka University
Email: {inoue, y-fujiwr}@ist.osaka-u.ac.jp

Abstract—Although researchers have created many advanced
code-clone detection techniques, more effort is required to realize wide adaptation of these techniques in the industry. Oneof the reasons behind this is the reliance of these advanced
techniques on lexing and parsing programs. Modern programming languages have complex lexical conventions and grammar,
which evolve constantly. Therefore, using advanced code-clone
detection techniques requires substantial and continuous effort.
This paper proposes a lightweight language-independent method
to detect code clones by simply finding repeated strings in a code
repository, relying on neither lexing nor parsing. The proposed
method is based on an efficient technique developed in a bioinformatics context to find repeated strings. We refer to therepeated strings in the source-code as weak Type-1 clones. Because
the proposed technique normalizes newlines, tabs, and whitespaces into a single white space, it can find clones in which
newline positions or indentations are changed, as often in thecase when copy-pasting occurs. Although the proposed method
only finds verbatim copies, it also makes interesting observations
regarding repository structures. Many developers may prefer the
proposed simple approach because it is easier to understand thanother advanced techniques that use heuristics, approximation,and machine learning.

I. I NTRODUCTION
Finding code clones (similar code fragments) has important
applications such as refactoring, fixing bugs, detecting copyright violations, and software traceability. The number of code
clones is a measure of the code quality because as the numberof code clones increases, the maintenance of software becomes
more difficult.
Code clones are classified into four types: Type-1, Type2, Type-3, and Type-4 clones [1]. Type-1 clones are thosethat match verbatim, for which only minor modifications, suchas changing newline characters or removing comments, areallowed. Type-2 clones are those for which changes in identifiers and literals are also allowed. If identifiers are changed
consistently (the same identifiers are modified to the same
identifiers), the clone is called consistent Type-II. Otherwise, it
is called blind Type-II. Type-3 clones are syntactically similarcode snippets for which addition or deletion of statements
is allowed. Type-4 clones refer to those that have functional
similarity but may not have syntactical similarity. Code clones
can also be classified based on their granularity (e.g., tokens,lines, statements, functions/methods, and files).

Most previous methods of finding code clones require lexing
and paring of the source code. The syntax of a modern programming language is often complex and frequently updated.
Therefore, developing and maintaining code-clone detection
tools based on lexing and parsing require substantial andcontinuous effort. Furthermore, a lexer and a parser makea code-clone detection tool language-specific, rendering the
deployment of such a tool inconvenient.
This paper proposes a lightweight code-clone detection
method, which is easier to develop and deploy; it finds
repeated strings, referred to as weak Type-1 clones in thecode. Finding repeated substrings in a string has been widely
studied in the bio-informatics context [2], [3], [4]. We adopted
Barenbaum et al.’s technique [4] and developed a tool called
CodeRepeat that can find all repeated strings in a software
repository. Unlike previous language-independent approaches,the proposed method replaces all newlines, white spaces, andtabs into single spaces; thus, it does not rely on newline
positions. Therefore, it can find a clone in which newline
positions are changed or removed, which is common in copypasted code, while always outputting exact matches. Further,it does not rely on any approximation methods such as
approximate substring matching or locality sensitive hashing.
Avoiding approximation methods, heuristics, or machine learning improves developers’ understanding of tools and reduces
false positives.
To make the proposed technique strictly language independent, comments are not removed. Thus, the proposed method
can only find a weak form of a Type-1 clone, but finding
such clones has legitimate application potential. Weak Type-1
clones indicate simple copy-pasting; they are easier to refactor
than Type-2 or Type-3 clones are. Finding verbatim copies,
including comments, provides strong evidence of plagiarism.
We also showed that CodeRepeat can find interesting clones
by applying the proposed method to large-scale open-sourcecode repositories. We found that large-scale source-code repositories often contain multiple copies of third-party libraries,
which are in different name spaces and have different versions.
These multiple copies of libraries are clearly intended bydevelopers and may be difficult to avoid, but they seriously
affect software maintenance.

This paper is organized as follows. Section II discusses
related works. Section III presents the algorithm used, its implementation, and the evaluation methods. Section IV presents
the evaluation results. Section V presents the conclusion of thisstudy.
II. R ELATED W ORKS
Extensive studies on code clones, targeting each clone type,have been conducted. Duplo [5] and Simian [6] primarily
target Type-1 clones by matching a hash value of each line.
CCFinder [7] and its new implementation, CCFinderX [8],tokenize the source code and target Type-1 and Type-2 clones.
NiCad [9] parses the source code and applies a transformation
to a syntax tree. NiCad targets Type-1, Type-2, and Type-3
clones. SourcererCC [10] uses heuristics based on a bag-inword approach to efficiently find Type-1, Type-2, and Type-3
clones. Sieamese [11] uses an n-gram-based method to quickly
find clones of a given code. CCAligner [12] specializes infinding clones with large gaps. Oreo [13] uses a neural method
to detect Type-3 and Type-4 code clones. For more complete
reviews and benchmarks, please refer to [1], [14], [15].
Among these tools, we select Duplo, CCFinderX, and
NiCad as baselines for comparison because they are mature
and widely used. Duplo, CCFinderX, and NiCad are representative text-, token-, and syntax-based methods, respectively.
CodeRepeat has an advantage over hash-based approaches
used by Duplo and Simian: they typically assume that the code
is separated by newlines. In contrast, CopeRepeat replaces all
newlines, tabs, and white spaces with single white spaces.
Therefore, CodeRepeat can find clones in which newline
locations or indentations are modified. Such modifications
are common when code is copy-pasted. We did not selectSourcererCC as a baseline because the Github version of
SourcererCC only supports Java and Python and not C/C++,
using which many open-source software are written. The lackof C/C++ support would suggest difficulties in supporting
multiple languages even for a token-based approach. We did
not compare CodeRepeat with CCAligner, Oreo, or Siamese
because their goals are different from those of ours. For many
developers, the behavior of a heuristic- or machine learningbased approach would be difficult to understand, whereasthat of CodeRepeat would be easy to understand because
it uses simple string matching. Further, we do not use any
approximation method, such as locality sensitive hashing or
approximate substring matching, because it can create many
false positives, unless it is fine-tuned. Although the proposed
method is simple, it found interesting clones in well-known
open-source code repositories.
III. M ETHOD
A. Algorithm
We identify code clones with either maximal repeats or
super maximal repeats [16] in the source code, dependingon the purpose of code-clone detection. Maximal repeats andsuper maximal repeats have precise mathematical definitions.

Definition 1: Let S be a string. We write a substring of S
from positions p1 to p2 (including the end) as S[p1 : p2 ].
• A maximal pair (p1 , p2 , l) is a pair such that S[p1 : p1 +l] = S[p2 : p2 +l] but S[p1 : p1 +l+1] ̸= S[p2 : p2 +l+1].
• A maximal repeat is a substring R of S such that R =S[p1 : p1 +l] = S[p2 : p2 +l], where (p1 , p2 , l) is a maximalpair.
• A super maximal repeat is a maximal repeat that is nota substring of any maximal repeat.
For example, in the string “abxabyabczabc,” “ab” and “abc”
are maximal repeats. “ab” is a maximal repeat because “abx”
is not repeated; therefore, the first occurrence of “ab” cannot
be extended. “abc” is the only super maximal repeat in thestring.
Many algorithms that efficiently find maximal pairs havebeen proposed in the bio-informatics context [2], [3], [4].
Barenbaum et al. [4] and Kulekci et al.’s algorithms [3]have the same asymptotic complexity (O(n)-space andO(n log(n))-time), whereas Beller et al.’s algorithm [2] hasO(n)-space and O(n)-time complexity. Barenbaum et al.’s
algorithm uses a suffix array to find maximal and super
maximal repeats. It is well known that we can find maximal and super maximal repeats using a suffix tree in linear
time [16]. However, a suffix tree is not practical for a large
input because of a large constant factor for space consumption.
Barenbaum et al. replaced suffix trees with suffix arrays;
efficient (O(n log(n))-time) construction of these suffix arrays
achieved lower memory requirement. Kulekci et al. used compressed data structures to achieve a further memory reduction.
However, unlike genome sequences, comprising four “alphabets,” the software code comprises bytes, with 256 characters.
This makes compressed data structures less memory-efficient.
Moreover, using compressed data significantly slows down thealgorithm. We experimentally compared Kulekci et al. [3]’sand Barenbaum et al. [4]’s implementations, which werekindly provided by the authors. Although both algorithms
have the same asymptotic complexity, Barenbaum et al.’s
algorithm is significantly faster, and its memory consumption
is comparable to that of Kulekci et al.’s algorithm. Therefore,
we select Barenbaum et al.’s findrepset for our implementation.
B. Implementation
Figure 1 presents an overview of CodeRepeat. CodeRepeat
treats files as pure byte strings (not Unicode characters).
First, a target code repository is preprocessed. To handle
a large number of files, CodeRepeat concatenates all files
into a single file. Although Barenbaum et al.’s findrepset cansimultaneously handle multiple files, the number of commandline arguments that can pass the subprocess call is limited.
Therefore, we chose passing a single file to findrepset.
Because we need to recover files and lines in which clones
appear, CodeRepeat generates “Charmap” and “Linemap,”
which provide mapping from locations in the concatenatedfile to file names and line numbers, respectively. CodeRepeat
also replaces newline characters, tabs, and sequences of whitespaces with single white spaces. We emphasize that theTABLE I
C ONFIGURATION OF TOOLS USED FOR B IG C LONE E VAL
Concatenated File

Preprocessing
Code- Concatenate all ﬁles
- Location table of ﬁlesand lines- Simple normalization

OutputTools
Filemapﬁndrepset

Charmap

Postprocessing- Mapping to ﬁles and line
numbers- Filtering- Split by ﬁle boundaries

Version

CodeRepeat
Duplo
CCFinderX
NiCad

Configuration

Not applicable
24 Sep, 2020
10.2.7.4
6.1

Maximal repeats, min length 40 bytes
Min length 6 lines
Minimum length 50 tokens
Min length 6 lines, max length 2500
lines, threshold 0.3

TABLE IITARGETED O PEN -S OURCE R EPOSITORIES
MaximalRepeats

Fig. 1. Implementation

normalization performed by CodeRepeat is much simpler thanlexing. A concatenated file is passed to findrepset. CodeRepeat
can instruct findrepset to find maximal or super maximal
repeats and the lower limits of length and frequency of
repeats that it finds. The generated maximal or super maximal
repeats are combined with information from Charmap andLinemap to obtain the locations of repeats in the source
files during the postprocessing phase. Postprocessing splits
a clone located across file boundaries into multiple clones.
Postprocessing optionally removes clones that solely consistof blank characters or are null. The output uses a simple JSON
format. Output compression is supported because the number
and size of maximal repeats can be very large.
C. Evaluation
We performed two experiments to examine the usefulness
of CodeRepeat. First, We perform the benchmark using BigCloneEval [17], which measures recall rates of different typesof clones in BigCloneBench [14], Type-I, Type-II (blind andconsistent), and Type-III with different degrees of syntacticalsimilarities, very strong (90% - 100%), strong (70% - 90%),and moderate (50% - 70%). BigCloneBench provides a wellcurated dataset of code clones extracted from open-sourceJava projects and is widely used to evaluate code-clone detection tools. We configured CodeRepeat to find small maximal
repeats (40 bytes). We configured CCFinderX using default
options. We configured NiCad and Duplo using default options
but smaller minimum size (6 lines) to find small clones.
The configurations used for BigCloneEval are summarized inTable I.
Next, we applied CodeRepeat, Duplo, CCFinderX, and
NiCad to large-scale open-source code repositories, OpenSSL,
Python, GCC, Firefox, and Android (Table II). Although we
aim to show that CodeRepeat is reasonably fast and memoryefficient, we are more interested in demonstrating the stability
and usefulness of the tools. Therefore, we measured the timeand memory used by each tool, collected errors that occurred

SoftwareVersionNumber of Lines (KLoC)

Language1

PythonOpenSSLGCC
FirefoxAndroid

3.8.5
1.1.1h
10.2.080.0
11.0.0r3

610
624
6311
11 20520 823

C/C++
C/C++
C/C++
C/C++
Java

1 For a project using multiple languages, the listed language was processed.

TABLE IIIC ONFIGURATION OF TOOLS APPLIED TO OPEN - SOURCE PROJECTS
Tools

Configuration

CodeRepeat
Duplo
CCFinderX
NiCad

Super-maximal repeats, min length 400 bytes
Min length 10 lines
Minimum length 50 tokens, detect only Type-1
Min length 10 lines, threshold 0.0, no custom contextual
normalization

TABLE IVR ECALL (OVERALL )Clone Class

CodeRepeat

Duplo

CCFinderX

NiCad

Type-1
Type-2Type-2 (blind)Type-2 (consistent)
Very-Strongly Type-3
Strongly Type-3
Moderately Type-3

100.0
60.0
2.4
65.2
11.1
3.1
0.1

38.2
40.3
0.5
44.0
0.5
0.3
0.4

98.6
88.5
72.1
90.0
27.1
9.7
0.5

99.9
99.9
99.6
99.7
99.4
63.0
0.4

during the execution of each tool. We configured each tool
as described in Table III for open-source projects to findlarger clones. For a fair comparison, we instructed CCFinderX
and NiCad to only find Type-1 clones. To demonstrate that
our method helps understand and restructure the source code
repository, we analyzed the top 5 largest clones in each sourcecode repository.
IV. R ESULTS
A. BigCloneEval
Table IV shows the recall rate obtained for each tool by
BigCloneEval. Although CodeRepeat was designed for weakType-1 clones, it found almost all Type-1 clones and a moderate number of Type-2 clones. Because CodeRepeat outputs
only exact matches, the precision of CodeRepeat should be
100%. Duplo performed poorly because it contains an integer
overflow bug.

TABLE VII
F IVE L ARGEST C LONE PAIRS IN THE F IREFOX R EPOSITORY F OUND BY
C ODE R EPEATTABLE VE XECUTION TIME ( SECONDS )Repositories

CodeRepeat

Duplo

CCFinderX

NiCad

PythonOpenSSLGCC
FirefoxAndroid

21
28
261
694
1398

399
219
2503
10 696
Not finished

209
219
2503
4230
6717

98
77
2087
528
FailedTABLE VIM EMORY CONSUMPTION (M EGA BYTES )Repositories

CodeRepeat

Duplo

CCFinderX

NiCad

PythonOpenSSLGCC
FirefoxAndroid

252
316
178
4778
9601

337
32
558
2910
Not finished

29
32
558
536
684

211
134
211
214
FailedB. Application to open source projects
Tables V and VI show the execution time and memory
consumption of each tool, respectively. The tools ran on amachine with an Intel Xeon E5-1603 v4 2.80GHz Quad Core,
32 GB RAM. CCFinderX ran as a native Windows application,
whereas the others ran in a Docker container using Ubuntu
20.0.4 LTS. CodeRepeat was equally as fast as baseline tools
and handled a project with more than 20 000 K lines of code.
It required more memory than baseline tools, but the memory
required was within the amount of available memory in amodern personal computer.
CodeRepeat handled all projects without any modification,
except for Android, in which a precompiled kernal directory
had to be removed because of an excessive number of nests ofsymbolic links. We applied same modification to the repository
used for other tools because the issue is not tool-specific.
Duplo required greater execution times for large projects, e.g.,
it did not finish for Android after running for 1 day. For
CCFinderX, we needed to remove files with null bytes in
GCC and manually extract Java files from Android projects.
NiCad failed to generate any result for Android and could
not parse many files, for example, 1251 files in GCC. It
shows that CodeRepeat can handle a complex code repository
without error, while other tools often cause errors whenhandling real-world projects. Being error-free is an important
property in practice, arguably more so than accuracy, recall,or performance, which are properties that modern code-clone
detection research is chasing.
Among the detected clones in each repositories, the case for
Firefox is particularly interesting, because we find that Firefox,
a widely used web browser, contains many large scale code
clones. Table VII shows the top five largest clones in Firefox.
The “Path” and “Line” columns show the location in which aclone pair is located. The “Description” column presents thedescriptions of a clone pair. As shown in the table, Firefox
contains three versions of SQLite, namely versions 3.32.3,
3.31.1, and 3.29.0, as separate packages. Although it would be

Path

Lines

Description

third party/sqlite3/src/sqlite3.cthird party/rust/libsqlite3sys/sqlite3/sqlite3.c

205312 – 224998
203984 – 223670

SQLite 3.32.3
SQLite 3.31.1

third party/sqlite3/src/sqlite3.cthird party/sqlite3/src/sqlite3.h1201 – 7023
162 – 6034

SQLite source
SQLite header

third party/sqlite3/src/sqlite3.cthird party/sqlite3/src/sqlite3.h1201 – 7023
162 – 6034

SQLite source
SQLite header

third party/rust/libsqlite3sys/sqlite3/sqlite3.cthird party/rust/libsqlite3sys/sqlite3/sqlite3.h1204 – 6992

SQLite source

162 – 5950

SQLite header

security/nss/lib/sqlite/sqlite3.csecurity/nss/lib/sqlite/sqlite3.h1206 – 6794
162 – 5750

SQLite 3.29.0
SQLite 3.29.0

TABLE VIIIF IVE L ARGEST C LONE PAIRS IN THE F IREFOX R EPOSITORY F OUND BY
CCF INDER X
Path

Lines

Description

third party/sqlite3/src/sqlite3.cthird party/rust/libsqlite3sys/sqlite3/sqlite3.c

200894 – 229013
199568 – 227684

SQLite 3.32.3
SQLite 3.31.1

third party/sqlite3/src/sqlite3.cthird party/rust/libsqlite3sys/sqlite3/sqlite3.c782 – 25858
785 – 25717

SQLite 3.32.3
SQLite 3.31.1

security/nss/lib/sqlite/sqlite3.cthird party/sqlite3/src/sqlite3.c787 – 20792
782 – 21461

SQLite 3.29.0
SQLite 3.32.3

security/nss/lib/sqlite/sqlite3.cthird party/rust/libsqlite3sys/sqlite3/sqlite3.c787 – 20792
785 – 21320

SQLite 3.29.0
SQLite 3.31.1

security/nss/lib/sqlite/sqlite3.cthird party/rust/libsqlite3sys/sqlite3/sqlite3.c39571 – 49157
40317 – 49908

SQLite 3.29.0
SQLite 3.31.1

intentional and may be difficult to avoid, this suggests that thedevelopers must update each instance of the library whenevera serious bug is found in these instances. Another finding wasthat many declarations were shared between source files andheader files, which would require simultaneous updating.
Although we do not present the details here, we also
observed that Android “repackages” the same libraries todifferent namespaces.
CCFinderX reported clones (Table VIII) between each version of SQLite in Firefox, whereas CodeRepeat only reported
clones between Versions 3.23.3 and 3.31.1 as the top 5 largest
clones. This indicates that CCFinderX is more powerful than
CodeRepeat in finding large-scale clones, although CCFinderX
requires tokenizers. CCFinderX discards comments, declarations, and variable definitions under the default setting, which
could have valuable information. NiCad reported clones (TableIX) in a small fragment, in which very few were more than

TABLE IX
F IVE L ARGEST C LONE PAIRS IN THE F IREFOX R EPOSITORY F OUND BY
N I C AD
Path

Lines

Description

security/nss/lib/zlib/inflate.c
modules/zlib/src/inflate.c

625 – 1275
625 – 1275

identical copy of zlib
identical copy of zlib

third party/rust/libzsys/src/zlib/inflate.c
modules/zlib/src/inflate.c

625 – 1275

identical copy of zlib

625 – 1275

identical copy of zlib

security/nss/lib/zlib/inflate.c
third party/rust/libzsys/src/zlib/inflate.c

625 – 1275
625 – 1275

identical copy of zlib
identical copy of zlib

third party/rust/libzsys/src/zlib/infback.c
security/nss/lib/zlib/infback.c

256 – 629

identical copy of zlib

256 – 629

identical copy of zlib

modules/zlib/src/inflate.c
security/nss/lib/zlib/infback.c

256 – 629
256 – 629

identical copy of zlib
identical copy of zlib

100 lines long, which was likely because NiCad respected
the function boundaries and separated clones there. Therefore,
it was difficult to see that there were large duplicated code
blocks between files from NiCad outputs. Although it has
been claimed that only clones that respect the function boundaries are useful [1], [14] for refactoring, clones with larger
granularity can help find large-scale structures of repositories
and restructure them. We did not analyze the output of Duplobecause of integer overflow bugs.
V. C ONCLUSION AND F UTURE W ORKS
In this paper, we introduced a new method for code-clone
detection using an efficient algorithm of finding repeatedsubstrings in a string, and we implemented a tool called
CodeRepeat. Because our method does not involve either
parsing or lexical analysis, it is language independent, easy to
implement, and robust against complexities in the source code.
Further, our method normalizes newlines, tabs, and sequencesof white spaces into single white spaces, and it can detectclones with different newline positions or different indentation, which commonly arise when copy-pasting occurs. Our
method always outputs exact matches and does not use any
approximation, heuristics, or machine-learning based method.
Its simplicity would improve developers’ understanding of tool
behaviors.
We applied BigCloneEval to CodeRepeat together with abaseline tool, Duplo, CCFinderX, and NiCad. The results
showed that CodeRepeat found almost all Type-1 clones anda moderate number of Type-2 clones, although it is based on
finding exact matches.
By applying large-scale open source repositories, we
showed that our method is as fast as existing methods andthat its memory consumption is within the capacity of amodern personal computer. Our tools are robust in realworld settings, whereas other tools often fail to process these
repositories correctly. Furthermore, we demonstrated that ourtool can find multiple instances of different versions of thesame library, duplicated macro definitions, declarations, andtable definitions. Such information is useful for maintaining,
updating, and understanding large-scale code repositories.
Our study has several limitations. First, we did not measure
the precision of CodeRepeat. Theoretically, the precision of
CodeRepeat should be 100%, but a potential bug may leadto a reduction in this precision. Second, we did not fine-tune
the configuration of baseline tools. For example, CCFinderX
has an option for controlling the number of token types in
the reported code clones. We observed that this option allows
CCFinderX to find variable-definition level clones. Third, weonly collected errors that appeared in the error messages.
Internal errors that did not appear in the error messages may
have led to incorrect processing. Finally, Duplo had a serious
bug due to which wrong line numbers were given as output,
thereby making its comparison to other tools could be unfair.
In future, we want to improve the algorithm to find the
maximal repeats. Beller et al.’s algorithm [2] is asymptoticallyfaster than Barenbaum et al.’s algorithm [4], and Beller etal.’s implementation reportedly consumes less memory. Using
Beller et al.’s algorithm may allow us to tackle larger software
repositories, such as the entire software packages of a Linux
distribution. The output of CodeRepeat has a JSON format,
which simplifies machine processing. However, the sheer
number of repeats reported makes it difficult for developers
to analyze. Thus, we need tools to analyze the output from
CodeRepeat to help developers understand the structure ofcode repositories. One possible direction is a tool to find onlyinter-project clones with large granularity, which would help
to track code evolution and source code traceability.
R EFERENCES[1] C. K. Roy, J. R. Cordy, and R. Koschke, “Comparison and evaluationof code clone detection techniques and tools: A qualitative approach,”
Science of Computer Programming, vol. 74, no. 7, pp. 470–495, 2009.
[2] T. Beller, K. Berger, and E. Ohlebusch, “Space-efficient computation of
maximal and supermaximal repeats in genome sequences,” SPIRE 2012,vol. 7608 LNCS, pp. 99–110, 2012.
[3] M. O. Kulekci, J. S. Vitter, and B. Xu, “Efficient maximal repeat finding
using the burrows-wheeler transform and wavelet tree,” IEEE/ACM
Transactions on Computational Biology and Bioinformatics, vol. 9,
no. 2, pp. 421–429, 2012.
[4] P. Barenbaum, V. Becher, M. H. A. Deymonnaz, and P. Heiber, “Efficient
repeat finding in sets of strings via suffix arrays,” Discrete Mathematics& Theoretical Computer Science, vol. 15, 2013.
[5] [Online]. Available: https://github.com/dlidstrom/Duplo[6] S. Harris, 2018. [Online].
Available: https://www.harukizaemon.com/simian/[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] [Online]. Available: http://www.ccfinder.net[9] J. R. Cordy and C. K. Roy, “The NiCad clone detector,” in ICPC 2011,2011, pp. 219–220.
[10] H. Sajnani, V. Saini, J. Svajlenko, C. K. Roy, and C. V. Lopes,“SourcererCC: Scaling code clone detection to big-code,” in ICSE 2016,
2016, pp. 1157–1168.
[11] C. Ragkhitwetsagul and J. Krinke, “Siamese: scalable and incremental
code clone search via multiple code representations,” Empirical Software
Engineering, vol. 24, no. 4, pp. 2236–2284, 2019.

[12] P. Wang, J. Svajlenko, Y. Wu, Y. Xu, and C. K. Roy, “CCAligner: a token
based large-gap clone detector,” in ICSE 2018, 2018, pp. 1066–1077.
[13] V. Saini, F. Farmahinifarahani, Y. Lu, P. Baldi, and C. V. Lopes, “Oreo:
Detection of clones in the twilight zone,” in ESEC/FSE 2018, 2018, pp.
354–365.
[14] J. Svajlenko and C. K. Roy, “Evaluating clone detection tools with
BigCloneBench,” ICSME 2015, pp. 131–140, 2015.
[15] ——, “A survey on the evaluation of clone detection performance andbenchmarking,” arXiv preprint arXiv:2006.15682, 2020.
[16] D. Gusfield, “Algorithms on stings, trees, and sequences: Computerscience and computational biology,” Acm Sigact News, vol. 28, no. 4,
pp. 41–60, 1997.
[17] J. Svajlenko and C. K. Roy, “Bigcloneeval: A clone detection toolevaluation framework with bigclonebench,” in ICSME 2016, 2016, pp.
596–600.