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

信学技報
TECHNICAL REPORT OF IEICE.

コードの生存期間を考慮したコードクローンと欠陥修正の関係調査
齋藤

晃†

吉田

則裕††

松下

誠†

井上

克郎†

† 大阪大学 大学院情報科学研究科 〒 565–0871 大阪府吹田市山田丘 1 番 5 号†† 奈良先端科学技術大学院大学 情報科学研究科 〒 630–0192 奈良県生駒市高山町 8916-5
E-mail: †{a-saitoh,matusita,inoue}@ist.osaka-u.ac.jp, ††yoshida@is.naist.jp
あらまし これまでにコードクローンと欠陥修正の関係について様々な報告がある．近年の研究においてコードクロー
ンはソフトウェアの欠陥を引き起こす要因に当たらないという報告がされているが，この調査ではコードの生存期間について考慮していないという問題がある．そこで本稿では，コードの生存期間に着目してコードクローンが欠陥修正に含まれる割合の調査を行った．その結果，生存期間が短いクローンの方が欠陥修正に多く含まれることが分かった．
キーワード

コードクローン，リポジトリマイニング，ソフトウェア進化

Investigation of Relationship between Code Clones and Defect Fixes by
Considering Period of Code Existence
Akira SAITO† , Norihiro YOSHIDA†† , Makoto MATSUSHITA† , and Katsuro INOUE†† Graduate School of Science and Technology, Osaka University
1-5, Yamadaoka, Suita, Osaka, 565–0871, Japan†† Graduate School of Information Science, Nara Institute of Science and Technology
8916-5, Takayama-cho, Ikoma, Nara, 630-0192, Japan
E-mail: †{a-saitoh,matusita,inoue}@ist.osaka-u.ac.jp, ††yoshida@is.naist.jp
Abstract Various reports exist on relationship between code clones and defects. Especially recent study said thatcode clones do not cause software defects. However, this study has a problem that the period of code existence is
not considered. Consequently, we investigated what proportion of code clones included defect fixes by considering
period of code existence. The result showed that defect fixes occurred more frequently in short-lived code clones
than long-lived ones.
Key words Code Clone, Repository Mining，Software Evolution

1. は じ め にている割合は小さく，コードクローンは欠陥を引き起こす要因に当たらないという結果が報告されている [5]．既存研究の調査

コードクローンとはソースコード中の全部又は一部の重複しでは公開されている欠陥情報管理システムから修正が完了した

たコード片であり，様々なコードクローンの検出手法が提案さ欠陥情報を取得し，取得した欠陥情報 (バグレポート) とリポジれている [3] [6] [8]．コードクローンがソフトウェアに与える影

トリから修正に該当するコミットを対応付ける手法を用いてい響に関してさまざまな報告がある．古典的には，Fowler らは重る．対応付けたコミットによって修正されたコード片全てを欠複したコード片が存在することを不吉な匂い (Bad Smell) と定

陥コードとみなし，欠陥コードはどの程度コードクローンを含義し，メソッドの抽出などにより重複を除去するべきと述べてんでいるかを調査している．しかしこの調査では，全ての欠陥

いる [4]．また，コードクローンはプログラムの可読性を低下さ

コードが単にコードクローンを含むかどうかのみ判断している

せ，ソフトウェアの保守の観点で望ましくないために積極的にだけであり，コードがそれまでにどの程度の期間存在していた除去すべきだとも言われている [2] [7]．その一方，ソフトウェ

かどうかについては考慮していない．

ア中の欠陥修正によって変更されたコード片を特定し，それら我々は，コードクローンの分析においてコード片の生存期間がどの程度コードクローンを含んでいるのかを調べたところ，が重要であると考えている．その理由として，既に修正が頻繁

コードクローンが欠陥修正によって変更されたコードに含まれに生じているコード片は今後も修正が生じやすいと考えられる—1—

欠陥管理システム

こと，また，たとえコードクローンであってもよく知られたプ
ログラミングロジックや長期間使われている実績のあるコードであれば，欠陥修正との関連は小さくなると考えられることが挙げられる．
そこで本稿では，既存研究で用いられた手法に加えコードの生存期間を考慮した上で欠陥修正がコードクローンを含む割合

コミットログを解析して対応付けの調査を行う．調査の結果，生存期間が短いコードクローンほ

コードがコードクローンを含む割合の算出方法について説明す

図1

る．3 節では本稿で適用する手法について述べ，4 節で結果のついて述べる．Rahman らの手法では下記の手順で解析を行っている．
（ 1 ） スナップショットの取得（ 2 ） コードクローンの検出（ 3 ） 欠陥修正と対応するコミットの取得（ 4 ） 欠陥修正に含まれるコードクローンの割合を算出
その後，既存研究の問題点について述べる．

2. 1 スナップショットの取得
版管理システムによって管理されているプロジェクトから，
過去のソースコード群を取得する．多くの版管理システムはリビジョンと呼ばれる単位でソースコードを含むファイルの変更を管理している．リビジョン r に含まれる情報を形式的に定義
すれば r = hA, T, f1 , f2 , ..., fn i と表される．ここで A は修正を行った作業者の名前を，T は時刻を，fi は修正が完了した後のファイル群を表す．全てのリビジョンを解析対象にすると計算時間・記憶容量が増大するため，既存手法では 1ヶ月おきに各リビジョンをスナップショットとして取得している．スナップ
ショットの集合 S は S = hs1 , s2 , ..., sn i と表され，si はそれぞれ毎月の最も日が早いリビジョンを表す．それぞれのスナップ
ショットに対して，その時点でのソースコードを全て取得する．

2. 2 コードクローン検出
取得したそれぞれの時刻におけるソースコード群に対してコードクローン検出を行う．検出には DECKARD を使用する [6]．コードクローン検出ツールを実行すると出力としてコー
ドクローンの集合 (クローンセット) が得られる．コードクロー
ン検出ツールの実行結果 O は O = hg1 , g2 , ..., gn i と表され，ここで gi は 1 つのクローンセットであり，gi = hc1 , c2 , ..., cn i と表せる． ci はクローンとなるコード片であり ci = hsj , fk , ls , le iと表せる． sj はコード片が含まれるスナップショットを，fk
はコード片が含まれるファイルを，ls と le はコード片の開始
行と終了行を表す．コードクローン検出処理によって，全てのコード片はコードクローンであるかユニークなコード片のどち

RESOLVED

・・・

・・・

・・・

・・・

リポジトリのコミットログ

bug fixed: #10002 ・・・------------------------------------------------------------------------

らの手法について述べる．ここでは欠陥コードの特定と欠陥

陥修正に含まれるとコードクローンの割合の調査を行ったかに

・・・

10002

-----------------------------------------------------------------------リビジョン番号r202 | authorName | 2009-02-01

本稿の構成を以下に示す．2 節では既存研究である Rahman

本節では既存研究である Rahman らの手法でどのように欠詳細

add feature: ・・・・

クローンは欠陥修正に含まれる割合が低くなることが分かった．

2. 関 連 研 究

状態

RESOLVED-----------------------------------------------------------------------r201 | authorName | 2009-01-01

ど欠陥修正に含まれる割合が高く，逆に生存期間が長いコード評価を行う．最後に 5 節で結論を述べる．

欠陥ID

10001

欠陥情報とリビジョンの対応付け

らかに分類される．
ここでコードクローン検出ツール DECKARD はパラメータとして h 最小トークン長，類似度，ストライド i の 3 つを与えることができるが，既存手法では h50, 1.0, 2i，h50, 0.99, 2i の 2
通りの実験結果を報告している．

2. 3 欠陥修正と対応するコミットの取得
欠陥を含むコード片がどこに存在するのか分かっていることが理想的であるが，一般に欠陥となるコード片の位置を特定することは困難である．そのため BugZilla 等の欠陥情報管理シ
ステムに登録されている修正済みのバグレポートを取得し，その欠陥の修正時に変更されたコード全てを欠陥コード (Buggy

Code) とみなす．欠陥情報管理システムに登録されているバグ
レポートから変更されたコードを特定するには，リポジトリから欠陥が修正されたコミットとバグレポートを対応付ける必要がある．この対応付けを行うために図 1 で示すように欠陥情報管理システムに登録されている欠陥 ID とリポジトリ内に保存されているコミットログを用いる．これらの対応付けの処理は
ヒューリスティックが用いられている [1]．代表的な対応付け基準は，•

欠陥 ID がコミットログに含まれている．

•“bug”, “ﬁxed” などの欠陥修正を表す単語が含まれている．
などである．欠陥修正情報とコミットの対応付けが出来れば，リポジトリからをバグレポートの修正に該当するコミットの前後の差分を diﬀ コマンドによって取得できる．欠陥修正がリビ
ジョン r で完了すれば，diﬀ コマンドで得られたリビジョン rとリビジョン r − 1 との差分が Buggy Code となる．

2. 4 欠陥修正に含まれるコードクローンの割合を算出
それぞれのバグレポートと修正されたコミットの対応付けの完了後，該当するリビジョン r と最も近いスナップショット sを対応付ける．そしてスナップショット s 中の Buggy Code の中に含まれるコードクローンの割合を算出する．欠陥修正が行われたリビジョン r とスナップショット s の間にコードの変更が生じる可能性があるので，diﬀ コマンドを用いて調整を行う．
例えば，リビジョン r とスナップショット s の間にコードが n行追加された場合，追加された行以降のコードの対応付けを n—2—

Buggy Code

前リビジョンに同じコード片が存在している
前リビジョンに同じコード片が存在していない

C1
C2

C2

C2
C3
C4

r2

1

ケ月

2009-03-01

r1

r0

rs

2009-04-01

2009-05-01

2009-06-01

図2

コード片の生存期間の取得

行ずらして行う．

コードクローン検出を行う．

2. 5 既存手法の問題点

このように条件を変更してコードクローンに包含されるコー

既存手法における問題点を以下に挙げる．

ド片の生存期間を取得した後，生存期間の長いコード片と短い•

コード片の存在期間について考慮していない．

コード片で欠陥修正に含まれる割合が異なるかどうかを調査•

Buggy Code を特定したリビジョンとスナップショットする．

との期間が長いと誤差が大きくなる．

また，欠陥 ID とコミットログの対応付けに関しては既存手

既存手法では，全てのコード片がコードクローンであるかユ法ではヒューリスティックな手法を用いており厳密に定義されニークなコード片であるかのどちらかに分類してそれらがどのていないので．ここでは最も単純に以下のようにして行う．

程度 Buggy Code に含まれているかを調査したが．コードがそ•

コミットログに該当する# で始まる欠陥 ID(# 100001

れまでにどの程度の期間存在していたかどうかについては考慮

等) が含まれていれば，その欠陥 ID を持つバグレポートとコしていない．コードの生存期間が重要である理由は，既に修正

ミットログを対応付ける．

が頻繁に生じているコード片は今後も修正が生じやすいと考え以降では Buggy Code に含まれていたコードクローンの生存期られ，また，たとえコードクローンであってもよく知られたプ間の算出方法について説明する．

ログラミングロジックや長期間使われている実績のあるコード

3. 1 コードクローンの生存期間の取得方法

であればそれらのコードは長期間存在して欠陥修正が行われにBuggy Code に含まれていたコードクローンの生存期間の算くいと考えられるからである．
また，Buggy Code を特定したリビジョンとスナップショッ

出は，以下の手順を用いて行う．
（ 1 ） Buggy Code 内に含まれるコードクローンの抽出と重トとの期間の間が長く，かつその間に変更が多く加わっている

複率の算出とスナップショットの時点ではコードクローンであったコード（ 2 ） コード片の変更の有無を過去のリビジョンと比較

片が修正時にはコードクローンでなくなっている可能性がある．

（ 3 ） コード片の生存期間を算出

そのため欠陥修正に含まれるクローンの割合の計算結果が誤差3. 2 Buggy Code 内に含まれるコードクローンの抽出と重複率の算出が生じる問題がある．

3. 実 験 方 法
前述の問題点を解決するために，以下の条件を変更した実験を行う．

Buggy Code のコードは位置は diﬀ コマンドによって取得され，コードクローンも検出時にコード位置が取得されている．
これらのコード位置の情報より Buggy Code 内に含まれるコー
ドクローンを特定し，以下のようにして重複率 d を求める．

（ 1 ） Buggy Code に一部でも含まれていたコードクローン
に対し，そのコードクローンに包含されるコード片の生存期間かを取得する．

d=lbuggyle − lb(1)

ここで ls ，le はコードクローンの開始行と終了行を，lbuggy は（ 2 ） スナップショットを 1ヶ月おきでなく欠陥 ID と欠陥

コードクローンの開始行と終了行の中で Buggy Code が含まれ修正のコミットの対応付けが完了した全てリビジョンにおいてる行数である．また，コードクローンは検出時にコードクロー

—3—

diff

の開始行
4.
lmb 1.

コード片の
開始行
lb

コード片

3.

le
コード片の
終了行

lme
diffの終了行 2.

rm
修正が行われた
リビジョン

rs
欠陥修正が行われた
リビジョン

4. 適 用 実 験
本節では前節で述べた実験を行った際の条件とその結果について述べる．

4. 1 実 験 条 件
既存研究では 4 つのオープンソースソフトウェアを実験対象としていたが，今回の実験ではそのうち２つのオープンソフト
ウェアを実験対象にした．対象とした２つのオープンソースソ
フトウェアの概要を以下に示す．

a ) Gimp

図 3 diﬀ による変更の有無の判定

オープンソースソフトウェアの画像編集ソフトウェア，2010
年 7 月時点でファイル数 2831，約 946kLOCンが含まれるリビジョン．ファイル名も取得する．

3. 3 コードの変更の有無を過去のリビジョンと比較b ) Evolution

手順１で抽出されたコードクローンに包含されるコード片にGnome デスクトップ環境に付随している標準メールクライ

最も新しく変更が加えられた時刻を算出する．図 2 で示すように

アント，2010 年 2 月時点でファイル数 1127，約 456kLOC

コードクローンに包含されるコード片が得られたリビジョン rs よいずれの対象もバグレポートは BugZilla で管理され，ソーり約 1ヶ月毎に過去のリビジョン群 r = hr0 , r1 , ..., rn i (ri < rs )スコードは Git リポジトリによって管理されている．BugZillaを取得する．取得したリビジョン群から下記の条件を満たすリで管理されているバグレポートのうち，下記の２つの条件を満ビジョン rm を取得する．

すもののみを抽出した．

•

rm = max ri ∗ δdif f (ri , rs , f, lb , le )(2)i

ここで δdif f は，リビジョン rs 中のファイル f 内の開始行 lb ，
終了行 le にあるコード片がリビジョン ri まで変化がなければ

1，そうでなければ 0 を返す関数と定義する．つまり rm はコー

バグレポートの “Status” が “RESOLVED”，“VERI-FIED”，“CLOSED” のいずれかに設定•

バグレポートの “Resolution” が “FIXED” に設定

コードクローン検出には既存手法同様に DECKARD を使用
した．パラメータ h 最小トークン長，類似度，ストライド i は

ドクローンに包含されるコード片のリビジョンより古く，かつ

h50, 1.0, 2i を用いた．

その中で最も新しい変更が生じたリビジョンを表す．コードの4. 2 実 験 結 果

変化は diﬀ コマンドにより変更のあった開始行 lmb ，終了行 lme

各プロジェクトにおける抽出したバグレポートの数，対応付が得られるので，図 3 に示すようにコードクローンに包含されけを行ったリビジョンの数を表 1 に示す．その後バグレポート

るコード片の開始行 lb ，終了行 le との間に以下の関係が満たさと修正を行ったリビジョンを対応付け，その中で欠陥コードにれれば，変更があったと判定する．

含まれるコードクローンを抽出した．抽出したコードクローン（ 1 ） lb > lmb かつ le >= lme : コード片の開始行をまたいだの数とその生存期間を表 2 に示す．ここでは生存期間最大とは，

変更

コードクローンに該当するコード片が修正されるまでの最も長（ 2 ） lb <= lmb かつ le < lme : コード片の終了行をまたいだ

い期間を日数で表したものである．

変更（ 3 ） lb <= lmb かつ le >= lme : コード片の内部の変更（ 4 ） lb > lmb かつ le < lme : コード片全体を包含する変更
上記の 4 つのそれぞれの条件は，図 3 において各番号の lmb ，lme の位置に差分が存在した時に対応している．

次に生存期間を取得したコード片を以下の 2 つのグループに
分類する．

•

Clong ・
・・ 生存期間 (中央値) よりも生存期間が長いコー

ド片のグループ•

Cshort ・・・ 生存期間 (中央値) よりも生存期間が短いコー

ド片のグループ

3. 4 コード片の生存期間の算出
手順２で求めたリビジョン rm と rs からそのコミットが行わそれぞれのグループにおいて，各コードクローンに包含された日時を取得する．その両者の日時の差を，コードクローンれるコード片が，BuggyCode 内に何割含まれていたのかを算の生存期間として算出する．

出する． Gimp プロジェクトと Evolution プロジェクトにおいて欠陥修正コード内に占めるクローンの割合を図 4 に示す．

表1

調査を行ったプロジェクトの概要
表 2 欠陥情報に含まれるコードクローンの概要

プロジェクト名

Gimp

Evolution

バグレポート数

698

11973

プロジェクト名

Gimp

Evolution1676

コードクローンの数

1093

1114

2004-01-11 2005-04-13

生存期間最大 (日)

3460

3812

2009-01-23 2010-08-20

生存期間最小 (日)3241

生存期間中央値 (日)

574

1791

対応付けたリビジョン数
最も古いリビジョンの日付
最も新しいリビジョンの日付

387

—4—

1.2

1.2

1

1

ジッ 0.8
レ 0.6
バ
カ
積0.4
累

ジッ 0.8レ
バカ 0.6積0.4
累

C_longC_shortC_longC_short

0.2

0.2
0

0
0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

欠陥修正に含まれるクローンの重複欠陥修正に含まれるクローンの重複率の重複率

1

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

欠陥修正に含まれるクローンの重複欠陥修正に含まれるクローンの重複率の重複率(a)Gimp プロジェクト

1(b)Evolution プロジェクト
図 4 欠陥修正コード内でクローンが占める割合

図 4 の横軸は欠陥修正に含まれるクローンの重複率であり，これはコードクローンを含む Buggy Code の全体行のうち，何割がコードクローンであったかを表している．縦軸はそれらの提案手法で取得できる生存期間
コード片そのものが存在する期間

コードクローンが全体の何割を占めているかの累積カバレッジ

C1であり，欠陥修正に含まれるクローンの重複率 d 以下の欠陥
修正が全体の何割存在するかを表している．図 4 では，Gimp,

C2

C2

r1

r0

クローン

C1

Evolution プロジェクトともに，生存期間が長いグループ Clongのほうが欠陥修正に多く存在する傾向があることが分かる．例
えば，Gimp プロジェクトにおいてクローン率 0.4 以下の欠陥

rs

図 5 提案手法で取得できる生存期間

修正は，生存期間が長いコード片のグループでは，78.0%を占めていたが，生存期間が短いコード片のグループでは 61.2%しか占めていない．同様に Evolution プロジェクトでもクローン率 0.5 以下の欠陥修正は生存期間が長いコード片のグループでは 82.0%を占めていたが生存期間が短いコード片のグループでは 71.0%であった．

する期間も考慮する必要がある．

4. 4. 2 コードクローンでないコード片に対しての生存期間の検討
本手法では生存期間が短いコードクローンはより欠陥修正が生じる頻度が高いかどうかを調査したが，コードクローンで4. 3 既存手法との結果の比較ない一般のコード片に対しては調査を行っていない．コードク

既存手法においても欠陥コードが含むコードクローンの割ローンと同様に，生存期間が短いコード片の方が欠陥修正が多合を示しており，Gimp プロジェクトでは約 2 割の欠陥修正がくなるかどうかを調べ，どの程度コードクローンとの差異が生

コードクローンを含んでいた．既存手法では類似度 1.00 と類似

じるかを調べる必要がある．そのためにはコード片の開始位置

度 0.99 でコードクローンを検出した結果を示しているが，どちを終了位置を設定する必要がある．

らもほぼ同じ分布を表していた．既存手法で示された欠陥コー

4. 4. 3 欠陥情報と対応付けが完了したリビジョン数の不足ドが含むコードクローンの割合を，コードクローンの生存期間

コミットログを用いて欠陥管理システムに登録されている欠に着目して分類することで図 4 に示すような差異を得ることが陥情報と欠陥修正に該当するコミットの対応付けを行ったが，できた．

対応付けが完了した欠陥情報は全体の一部しかない．Gimp で

4. 4 考察は約 55%，Evolution は約 14%の欠陥情報しか対応付けできて今回の実験における問題点・考慮すべき点を述べる．

いない．そのため，欠陥情報全体の性質を把握できているわけ

4. 4. 1 コード片としての生存期間の取得方法の妥当性のではない．この問題は既存手法も同様であり，対応付けをより検討
今回の手法ではコード片の生存期間の取得方法として，過去のリビジョンでコード片の位置に該当する場所に変化があるか正確に行える手法を適用し，既存手法と本実験の両者の方法で再度比較検討する必要がある．

を調べることで判断した．しかし，図 5 のように，リビジョン

5. お わ り に

rs より過去のリビジョンにおいて，リビジョン rs に存在する

本稿では，コード片の生存期間を考慮してコードクローンはコード片と別の位置にコード片が出現した場合，コード片その欠陥修正にどの程度含まれるかを調査した．既存手法であるものが存在する期間が取得できない．ソースコード全体からRahman らの手法は公開されている欠陥情報管理システムから

コード片が存在してるかどうかを判定するためには，過去のリ

欠陥情報を取得し，コミットログを用いて欠陥修正が行われた

ビジョンにおいてもコードクローン検出を実行しそれらの存在—5—

リビジョンを対応付ける手法を用いている．さらに欠陥修正によって修正されたコード片がどの程度コードクローンを含むのかを調査した．本手法では既存手法に加えてコードクローンの生存期間に着目した．生存期間が短いコード片のグループと生存期間が長いコード片のグループの２つに分割し，それぞれが欠陥修正に含まれている割合を調査したところ，生存期間が短いコード片のグループの方が欠陥修正に多く含まれるという結果が得られた．今後はコードの生存期間の取得方法を変更し，コード片がソースコード中に含まれる期間を算出して同様の実験を行うことを考えている．また，コードクローンでないコー
ド片に対しての生存期間を取得し，それがコードクローンであるコード片と差異が存在するか等を検討する予定である．今回使用したコードクローン検出ツールは既存手法と同じにするた
めに DECKARD を用いたが，CCFinder 等の異なるコードク
ローン検出ツールでも同様の実験を行うことを考えている．
謝 辞 本 研 究 は 一 部 ，日 本 学 術 振 興 会 科 学 研 究 費 補 助
金 基盤研究 (A)(課題番号:21240002)，基盤研究 (C)(課題番
号:22500026)，研究活動スタート支援 (課題番号:22800040) の助成を得た．
文

献[1] A. Bachmann and A. Bernstein. Data retrieval, processing
and linking for software process data analysis. Technical report, Dynamic and Distributed Information System Group,
Departmenet of Informatics, University of Zurich, 2009.
[2] M. Balazinska, E. Merlo, M. Dagenais, B. Lagüe, andK. Kontogiannis.
Advanced clone-analysis to support
object-oriented system refactoring. In Proceedings of the 7th
Working Conference on Reverse Engineering(WCRE’00),
pp. 98–107, Los Alamitos, USA, 2000.
[3] I. D. Baxter, A. Yahin, L. Moura, M. Sant’Anna, and
L. Bier. Clone detection using abstract syntax trees. In
Proceedings of the IEEE International Conference on Software Maintenance(ICSM’98), pp. 368–377, Los Alamitos,
USA, 1998.
[4] M. Fowler. Refactoring: improving the design of existingcode. Addison Wesley, 1999.
[5] F.Rahman, C.Bird, and P. Devanbu. Clones: What is thatsmell? In Proceedings of the Seventh IEEE Working Conference on Mining Software Repositories(MSR’ 10), pp. 72–
81, Cape Town, South Africa, 2010.
[6] L. Jiang, Z. Su G. Misherghi, and S. Glondu. DECKARD:scalable and accurate tree-based detection of code clones.
In Proceedings of the 29th International Conference on
Software Engineering (ICSE 07), pp. 96–105, Minneapolis,
USA, 2007.
[7] L. Jiang, Z. Su, and E. Chiu. Context-based detection ofclone-related bugs. In Proceedings of the 6th joint meeting of the European software engineering conference andthe ACM SIGSOFT symposium on the foundations of software engineering(ESEC-FSE ’07), pp. 55–64, Dubrovnik,
Croatia, 2007.
[8] T. Kamiya, S. Kusumoto, and K. Inoue. CCFinder: A
multilinguistic token-based code clone detection system forlarge scale source code. IEEE Transactions on Software
Engineering, Vol. 28, No. 7, pp. 654–670, 2002.

—6—