VOL. J103-D NO. 4
APRIL 2020
本PDFの扱いは、電子情報通信学会著作権規定に従うこと。
なお、本PDFは研究教育目的（非営利）に限り、著者が第三者に直接配布することができる。著者以外からの配布は禁じられている。

論

学生論文特集文

多様なプログラミング言語に対応可能なコードクローン検出ツール
CCFinderSW*
瀬村雄一† a)

吉田則裕†† b)崔恩瀞††† c)井上克郎† d)CCFinderSW: Clone Detection Tool with Flexible Multilingual Tokenization∗
Yuichi SEMURA†a) , Norihiro YOSHIDA††b) , Eunjong CHOI†††c) ,and Katsuro INOUE†d)

あらまし 近年実務に使用されるプログラミング言語は多様化し，ある一つのプログラミング言語においてもその文法はバージョンごとに差異をもつ．字句単位のコードクローン検出ツール CCFinderX は，多様な言語に対応するためのシンプルな仕組みをもたない．提案ツールとして，構文解析器生成系の一つである ANTLRの構文定義記述を入力として与えることで，新たな言語の字句解析が可能になるコードクローン検出ツール
CCFinderSW を開発した．評価実験では，42 言語の構文定義記述からコメントや予約語，文字列リテラルの情報を抽出し，81%の言語でこれら 3 種類の情報が抽出可能であることを示した．また，C++で記述されたソースコードに対するコードクローン検出において CCFinderX と出力を比較し，ほぼ同等の検出能力をもつことを
示した．
キーワード

コードクローン，字句解析，ANTLR

案されているが [3]，近年では実務に使用されるプログ

1. ま え が き

ラミング言語は多様化し，ある一つのプログラミング

コードクローンとは，ソースコード中に存在する互言語においても，バージョンによってその文法には差いに一致，または類似したコード片を指し，主に既存異がある．しかし，既存のコードクローン検出ツールのコード片のコピーアンドペーストによって生成されは，多様なプログラミング言語に対応するためのシンる [1]．一般的にコードクローンの存在は，ソフトウェ

プルな仕組みをもたない [4]．

ア保守を困難にしている大きな要因の一つとして挙げ

コードクローン検出ツールの一つである CCFind-

られている．あるコード片にバグが見つかった場合，

erX は，C++，C#，Java，COBOL，Visual Basic

そのコード片のコードクローンにもバグが含まれるの言語で記述されたソースコードからコードクローン

可能性が高い．そのため，開発者はあるコード片にバを検出することが可能である（注 1）．CCFinderX は字

グが見つかった場合，そのコード片の全てのコードク

句単位のコードクローンを検出するための前処理としローンに対して同一の修正を行うか検討する必要があて，ソースコードを言語の文法に沿って字句単位に分る [2]．現在まで多くのコードクローン検出ツールが提割している．一般的に字句解析と呼ばれるこの処理に†††よって，ソースコードのフォーマット，コメントの有大阪大学，吹田市
Osaka University, Suita-shi, 565–0871 Japan無，変数名や関数名の違いを無視した実用的で意味の名古屋大学，名古屋市あるコードクローンを検出することができる [5]〜[8]．

Nagoya University, Nagoya-shi, 464–8601 Japan†††

京都工芸繊維大学，京都市
Kyoto Institute of Technology, Kyoto-shi, 606–8585 Japana) E-mail: y-semura@ist.osaka-u.ac.jpb) E-mail: yoshida@ertl.jp

CCFinderX は，新たな言語の字句解析部を実装することでコードクローン検出が可能になる仕組みをもつが，この字句解析部の実装は手間のかかる作業である．
このような場合に，新たな言語に容易に対応するため

c) E-mail: echoi@kit.ac.jpd) E-mail: inoue@ist.osaka-u.ac.jp* 本論文は学生論文特集秀逸論文である．
DOI:10.14923/transinfj.2019PDP0025

電子情報通信学会論文誌（注 1）：http://www.ccfinder.net/

c 一般社団法人電子情報通信学会 2020
D Vol. J103–D No. 4 pp. 215–227 

215電子情報通信学会論文誌 2020/4 Vol. J103–D No. 4のシンプルな仕組みを利用することで，ツール開発者

クローンとなるコード片はクローンペアと呼ばれ，クの手間を減らすことができる [9]．

ローンペアにおいて推移関係が成り立つコードクロー

本研究では，多様なプログラミング言語に容易に対応

ンの集合はクローンセットと呼ばれる．またクローン

することができるコードクローン検出ツールの開発をペアの二つのコード片に対し，それぞれを包含するい目的として，構文解析器生成系の一つである ANTLR

かなる字句列も等価でないとき，極大クローンペアとで利用される構文定義記述から，字句解析に必要な文呼ぶ．

法を自動的に抽出するモジュールを開発した．そして

コードクローンには，普遍的定義は存在しない．本このモジュールが抽出した文法を用いて，言語の文法

論文では，コードクローンの定義として二つの分類をに沿ったコードクローン検出が可能な CCFinderSW

用いる [10]．タイプ 1 のコードクローンは，空白，タを開発した．CCFinderSW の利用者は，構文定義記

ブ文字，改行やコメントなどを除いて一致するコード述が集められたリポジトリ grammars-v4（注 2）から対象

クローンを指す．タイプ 2 はタイプ 1 の条件に加えて，言語の構文定義記述を取得し，ツールの実行時に入力

リテラル，型，識別子を除いて一致するコードクローとしてそのまま与えることでコードクローン検出を行

ンを指す．タイプ 2 のコードクローンを検出することうことができる．

で，変数名に差異があるが類似した処理を行うクロー

また，CCFinderSW に関する三つの評価実験を行っ

ンペアをリファクタリング候補として提示したり，変た．一つ目の実験では，ANTLR で利用できる構文定

数名の修正漏れを含むコードクローンを検出したりす

義記述を集めたリポジトリ上の 42 の構文定義記述をることができる [7], [8]．

対象に，本研究で開発したモジュールがどの種類の文

CCFinderX は，C++，C#，Java，COBOL，Vi-法を抽出可能かを確認した．二つ目の実験では，C++sual Basic といったプログラミング言語に対応した字のソースコードに対してコードクローン検出を行い，句単位のコードクローン検出ツールであり，タイプ 1

CCFinderX と CCFinderSW の検出結果の差異を分とタイプ 2 のコードクローンを検出することができ析した．最後に，Verilog HDL のソースコードに対しる．CCFinderX は字句単位のコードクローンを検出て CCFinderSW を用いてコードクローン検出を行い，するための前処理として，ソースコードを言語の文法

Precision と Recall を測定した．

に沿って字句単位に分割している．一般的に字句解析

以降，2. では本研究の背景としてコードクローンと呼ばれるこの処理によって，ソースコードのフォーについて，そしてコードクローン検出ツールである

マット，コメントの有無，変数名や関数名の違いを無CCFinderX の説明を行う．3. では，構文解析器生成視した実用的で意味のあるコードクローンを検出する系の一つである ANTLR の本研究での利用方法につことができる [5]〜[8]．

いて説明し，次に構文定義記述から文法情報を抽出す

以下に，CCFinderX を構成する四つの Step につる手法について説明を行う．4. では三つの評価実験にいて記述する．

ついて記述し，6. ではまとめと今後の課題について述

Step 1: 字句解析

べる．

2. 背

ソースコードをプログラミング言語の文法に沿って

景

本章では本研究の背景として，コードクローンとその字句列に変換する．この際，空白とコメントは機能に影響しないので無視される．

Step 2: 変換処理

分類，コードクローンの検出技術について記述し，字句分割された字句列のうち，識別子を同一の字句に変単位のコードクローン検出ツールである CCFinderX

換する．この処理はタイプ 2 のコードクローンを検出についての説明を行う．

するために行われる．

コードクローンとは，ソースコード中に存在する互Step 3: クローン検出

いに一致，または類似したコード片を指す．コードク

変換された字句列を比較し，コードクローンを検出

ローンは，主に既存のコード片のコピーアンドペース

する．比較には，suﬃx-tree を用いたアルゴリズムをトによって生成される [1]．一般的に，互いにコード採用している．

Step 4: 出力整形
（注 2）
：https://github.com/antlr/grammars-v4

216

検出されたコードクローンをクローンペアとして，

論文／多様なプログラミング言語に対応可能なコードクローン検出ツール CCFinderSW
表1

コードクローン検出ツールとその対応言語

ツール名
CCFinderX
DECKARD [11]SourcererCC [12]Oreo [13]DeepSim [14]対応言語
Java, C/C++, COBOL, Visual Basic, C#
Java, C, PHP, Solidity
Java, C/C++, Python
Java
Java

出現するファイル・行番号などを出力する．

CCFinderX は，新たな言語の字句解析部を実装することでコードクローン検出が可能になる仕組みをもつが，この字句解析部の実装は手間のかかる作業である．既存のコードクローン検出ツールの問題点として，多様なプログラミング言語に対応するためのシンプルな仕組みをもたないことが挙げられる．
また，CCFinderX など数多くのコードクローン検出
ツールが開発されているが，表 1 に示すとおり対応プ
ログラミング言語の数は限られる．表 1 は，CCFind-

erX 及び主要国際会議で発表されたコードクローン検出ツール四つとそれらの対応言語である．

3. 提案ツール：CCFinderSW

図1

CCFinderSW の処理概要

本研究では多様なプログラミング言語に対応した
コードクローン検出ツールを開発することを目的として，字句単位のコードクローン検出における字句解析に必要な文法情報を，構文解析器生成系の一つである ANTLR の構文定義記述から自動的に抽出するモジュールを開発した．そしてそのモジュールを用
いて，ANTLR の構文定義記述を入力として与える
ことで，多様な言語のコードクローン検出が可能な

CCFinderSW を開発した．CCFinderSW は GitHub
で公開されている（注 3）．

3. 1 では CCFinderSW の処理概要と各処理の詳細について記述し，3. 2 では構文定義記述解析モジュールの開発について記述する．

3. 1 CCFinderSW の処理概要
図 1 は CCFinderSW の処理概要を表したものである．これは CCFinderX の処理概要に基づき，ソース
コードを入力としてクローンペア情報を出力するために，字句解析，変換処理，クローン検出，出力整形を行う．本ツールは Java を用いて，一から実装を行った．構文定義記述解析モジュールは，字句単位のコー
ドクローン検出が行う言語依存の処理であるコメント
除去及び識別子変換に必要な文法を，ANTLR の構文（注 3）：https://github.com/YuichiSemura/CCFinderSW

定義記述から抽出する．具体的には，コメントや文字
列リテラル，予約語の文法を抽出し，正規表現として出力する．字句単位のコードクローン検出手法は，等価な字句列をコードクローンとして検出するため，字
句解析は行うが構文解析は行わない．そのため，字句解析で利用するコメントや文字列リテラル，予約語の文法のみ抽出すれば，コードクローン検出を行うことができる．字句解析部はコメントと予約語を表す正規表現を用いてコメント除去を行う．本ツールの字句解
析を，コメント除去，字句分割，識別子判別の三つの処理に細分化した．以降，各処理の詳細について記述
する．

3. 1. 1 コメント除去と文字列リテラルの識別
コードクローンにはコメントや空白は含まれないという定義に基づき，入力されたソースコードのコメン
トを除去する処理である．コメント除去に使用する手法としては，ソースコード中からコメントを表す正規表現にマッチする文字列を選び出し，同じ文字数の空白に置換している．
文字列リテラル内にコメント記号が書かれた場合，コメントではなく文字列リテラルであると認識する必要がある [15], [16]．図 2 は，C 言語のソースコード
217電子情報通信学会論文誌 2020/4 Vol. J103–D No. 4

図2

文字列リテラル内にコメント記号が含まれる例の一部である．このソースコードに対し，C 言語コメントの文法を表す正規表現（注 4）のみを用いてマッチを

図 3 四則演算式を表す構文定義記述行った場合，コメントを表す部分に正しくマッチしな
い．マッチングしたい文字列は青字の部分であるが，実際にマッチした部分の開始地点はダブルクオーテー
ションに囲まれた /∗ になってしまう．この対策として，文字列リテラルを正規表現を用いて識別する必要がある．

3. 1. 2 字 句 分 割
コメント除去が行われたソースコードに対して，字
句分割を行う．字句分割で使われるルールは以下のとおりである．番号が小さいルールほど優先される．
（ 1 ） 文字，文字列リテラルは 1 字句とする．
（ 2 ） 空白，タブ文字と改行の前後で字句を分割する．
（ 3 ） 記号は 1 文字ずつで分割する．記号が複数文字で一つの意味を表す場合でも，1 文字で 1 字句とする．
（ 4 ） それ以外の連続した英数字列は 1 字句とする．

3. 1. 3 識別子判別・変換処理
識別子判別では字句分割で英数字列として分割された字句が，識別子か予約語かを判定するものである．
予約語は変数名や関数名に使用できない文字列のことを指す．予約語の集合は，プログラミング言語ごとにそれぞれ定義されている．変換処理は CCFinderX の処理と同様に，識別子を同一の字句に変換するものである．

3. 1. 4 クローン検出・出力整形
クローン検出では変換された字句列を比較し，コー
ドクローンを検出する．CCFinderSW の開発には，Ngram を用いたアルゴリズムを採用している [17]．最後に出力整形では，検出されたコードクローンをク
ローンペアとして，出現するファイル・行番号などを出力する．

3. 2 構文定義記述解析モジュールの開発
本研究で開発した構文定義記述解析モジュールは，

ANTLR の構文定義記述を構文解析し，生成した構文木から必要な情報を取得する．この構文解析には，（注 4）：例えば，/\ ∗ [\s\S]∗?\ ∗ /|//((?![\r\n])[\s\S])∗218

Java で動作する構文解析器を ANTLR で生成して組み込んだ．
以降，3. 2. 1 では ANTLR の構文定義記述について，及び本研究で利用した理由について説明する．3. 2では新たに開発した構文定義記述解析モジュールの実
装について説明する．3. 2. 2 から 3. 2. 4 ではコメン
ト・文字列リテラル・予約語のそれぞれにおける，正規表現への変換手法について説明する．

3. 2. 1 構文解析器生成系 ANTLR の構文定義記
述の利用
本節では，本研究で利用した ANTLR の構文定義
記述の文法と，調査を行った構文定義記述に頻出した表現方法について説明する．
構文解析器生成系は，字句解析器や構文解析器を自動的に生成するプログラムであり，パーサジェネ
レータとも呼ばれる．構文解析器生成系の一つである

ANTLR は，構文木の構築・探索が可能な構文解析器を生成する．Twitter（注 5）での検索クエリの解析に採用されるなど，ANTLR は広く使用されているため [18]，
本研究の対象として選択した．
ここで，図 3 に ANTLR の構文定義記述の例を示し，用いられる文法について説明する．まず，以下の構文定義記述の 1 行目では，grammar Prog と書くことで構文定義記述が表す文法の名前が Prog であることを宣言している．2 行目以降は文法を構成するルールについて記述している．先に示した四則演算
式を表す記述の中では，字句解析ルールとして ‘INT’と ‘WS’ が存在する．‘INT’ は数字列を表していて，‘WS’ は空白とタブ文字と改行を表している．
一つのルールは ‘ルール名:ルールブロック’ のように記述され，このようなルールを複数組み合わせることで一つの文法を形成する．ANTLR の文法を定義するルールには，字句解析ルールと構文解析ルールの二つが存在する．字句解析ルールの名前は大文字から（注 5）：https://twitter.com/

論文／多様なプログラミング言語に対応可能なコードクローン検出ツール CCFinderSW
表2

ANTLR で使用される主要な字句

字句‘リテラル’[文字集合]

説明文字，または文字列にマッチする．
指定された文字のどれか一つにマッチする．a-zのように書くことで範囲を指定することも可能．
正規表現で使用されるものと同様．
. 任意の一文字にマッチする∼x x で記述されている集合にマッチしない任意の一文字にマッチする．x は 1 文字のリテラルや文字集合が指定される．本論文では NOT 演算子と呼ぶ
x* x の 0 回以上の繰り返しにマッチする．
x? x の 0 回，または 1 回の出現にマッチする．
x*? x の 0 回以上の最短の繰り返しにマッチする．
x|y x または y にマッチする．

図 4 コメントの定義例

Step で行われる．
Step A 全てのルールの中から，コメントを表すルールを選びだす．

Step B 別のルールを参照している部分を再帰的に適用する．

Step C Java で使用される正規表現に変換する．
始まり，構文解析ルールの名前は小文字から始まる．

Step D 生成された正規表現を全て結合して一つのANTLR で用いられる表現については，ANTLR の開表現にする．

（注 6）

発者によるドキュメントが存在する．その中から

主要な字句解析ルールを抜粋し，表 2 に示す．

各 Step の詳細は以下のとおりである．

Step A まず，全てのルールの中からコメントを

次に，ANTLR で使用されるコマンドについて説明

表すルールを選び出す．判断基準を四つ設け，そのうする．ANTLR は字句解析ルールを用いてソースコー

ちの少なくとも一つに当てはまることでコメントを表

ド中で出現する字句を定義するが，それぞれの字句にすルールとして識別した．その四つの判断基準を以下

コマンドを指定し，特定の操作を施すことができる．

に示し，それぞれに当てはまるルールを図 4 に例示すコマンドは，通常のルールの後に‘->’ とコマンドる．例示された四つのルールは，いずれも C 言語の複名を加えて記述する．本研究で扱ったコマンドは二数行コメントに相当する表現である．

つである．一つ目は skip である．skip を指定された（ 1 ） ルール名に ‘comment’ という文字列が含まれ字句は，字句解析によって読み飛ばされる．二つ目はている．このとき，大文字と小文字の差異は無視する．

channel コマンドである．channel(x) のように記述し，（ 2 ） skip が呼ばれている．

x にはあらかじめ定義された channel 名が入る．特に（ 3 ） channel(HIDDEN) が呼ばれている．

channel(HIDDEN) は skip と同じ処理を行い，このコ（ 4 ） channel が呼ばれていて，channel 名に ‘com-

マンドを指定された字句は ANTLR の Parser によっment’ という文字列が含まれている．このとき，大文て無視される [19]．

字と小文字の差異は無視する．

3. 2. 2 コメント文法の正規表現への変換

Step B 選び出されたルールの中で，別のルールを

本節では ANTLR の構文定義記述から，コメントを参照している部分を再帰的に適用する．3. 2. 1 で示し表す正規表現の抽出方法について述べる．文法情報をた四則演算式を表す構文定義記述の例では，term と正規表現で抽出した理由としては，一般的に正規表現いう名前のルールの中で factor というルールが埋め込

は文字列の置換処理などに用いられることが多く，提まれている．このようにルールの中で他のルールが参案ツールの実装言語である Java においても，正規表照されている場合は，Step C で正規表現に変換する

現を用いた文字列処理に関する標準ライブラリが存在ために参照先のルールの内容を再帰的に適用する．正するためである．また，ANTLR の構文定義記述は正規表現で表現できないコメント文法を解析する場合な

規表現と近い表現が用いられており，変換が容易であどに，再帰的適用が停止しない場合があるため，ルーるためである．更に，コメント除去に正規表現を用いルを適用するたびに二つ組（ルール，対象の記号）をることで，既存ツールで採用されている分類以外のコ記録する．この記録を用いて，過去に同一の二つ組でメント文法にも幅広く対応できると考えている．

表される適用が行われていれば再帰的適用を停止する．

コメント文法の正規表現への変換は以下の四つのStep C Step B で適用されたルールを，CCFinderSW の開発言語である Java で使用可能な正規表現（注 6）：https://github.com/antlr/antlr4/blob/master/docに変換する．正規表現と構文定義記述で用いられる表219

電子情報通信学会論文誌 2020/4 Vol. J103–D No. 4

図 6 文字列リテラルの定義例

図7

図 5 コメント記述ルールの正規表現への変換例

予約語の定義例

ラル文法を抽出し，正規表現へ変換する方法について述べる．

現の違いで，変換が必要なものは三つある．
一つ目はシングルクォーテーションである．ANTLRの構文定義記述では，対象言語に出現する実際のリテ本研究では，ANTLR の構文定義記述内での文字列
リテラルの記述法を調査した．図 6 に示すのは，調査対象の中に多く存在したものである．

ラルをシングルクォーテーションで囲んで記述する．

1 行目のルールでは，ルール名に ‘String’ という文

正規表現ではこのシングルクォーテーションは不要

字列が含まれており，文字列リテラルが定義されていであるため除去する．二つ目は NOT 演算子である．

る．2 行目のルールは，ルール名に ‘STRING’ が含ま

ANTLR の構文定義記述では，ある特定の文字集合にれているが予約語の定義である．1 行目のようなルーマッチしない集合を表すために先頭に，NOT 演算子

ルだけを抽出するために，文字列リテラルのルールのの役割をする ‘∼’ をつける．この NOT 演算子に直接判断基準を，「ルール名に ‘STRING’ という文字が含的に相当するものは正規表現には存在しないため，正まれるもののうち，予約語の定義ではないルール」と規表現の否定的先読みを用いて同等の表現に変換する．

した．このとき，大文字と小文字の差異は無視する．

三つ目は ‘.’ である．ANTLR の構文定義記述では ‘.’
は任意の 1 文字を表すのに対し，Java で使用される

構文定義記述から正規表現への変換は，コメントの場合と同様であるため説明を省略する．

正規表現では改行以外の任意の 1 文字を表し，定義が3. 2. 4 予約語一覧の正規表現への変換

異なっている．この定義の差異を埋めるため，構文定

本節では ANTLR の構文定義記述から予約語一覧

義記述で用いられる ‘.’ を正規表現での同等の表現でを抽出し，正規表現へ変換する方法について述べる．

ある ‘[\s\S]’ に変換することで対応している．

Step D 生成された正規表現を全て結合して一つANTLR の構文定義記述内での予約語の記述法を調査した結果，大きく分けて 2 種類の記述法があった．

の表現にする．これは Step C で生成された全ての正以下の図 7 に，while という予約語の定義に対する 2

規表現の間に，論理和を表す記号である ‘|’ を挟んで種類の記述法を例示する．

結合することで行われる．

1 行目のルールでは，W HILE というルール名に

図 5 は，コメントに相当するルールの正規表現へ

while という単語が紐付けられている．この記述法はの変換例である．まず Step A では判断基準に基づ

最も広く使われているものであった．そして二つ目のいて，BComment と LComment というルールを選ルールでは文字クラスを用いた記述法が使用されてい択する．次に Step B ではこの選択されたルールで，る．これは while に含まれる 5 文字のそれぞれに大文他のルールを参照している部分を再帰的に適用する．

字と小文字のどちらでもマッチすることを許す記述法

BComment では CST ART と CEN D という他のである．このような 2 種類の記述法を抽出するために，ルールへの参照があるため，参照先のルールを代入し予約語一覧の正規表現への変換は以下の五つの Stepて他のルール名が含まれない表現にする．Step C でで行われる．

は Java で使用可能な正規表現に変換し，Step D で全

Step αての正規表現を結合する．

うち英字列に一致するものを抽出する．

全てのルールで，出現しているリテラルの3. 2. 3 文字列リテラル文法の正規表現への変換

Step β

本節では ANTLR の構文定義記述から文字列リテ

る部分に再帰的に適用する．

220

全てのルールで，別のルールを参照してい論文／多様なプログラミング言語に対応可能なコードクローン検出ツール CCFinderSW

らかじめ手作業で記録し，構文定義記述解析モジュールが正しく情報を抽出できるかどうかを判定した．
本研究における予約語の定義について記述する．予
約語とは，変数名や関数名に使用できない文字列のことを指し，言語によって定められている．一方，プロ
グラミング言語におけるキーワードとは，特別な役割をもつ文字列のことを指す．予約語とキーワードは似通った存在と言われているが，言語によってはキー
図 8 予約語一覧の正規表現への変換例

ワードであっても予約語ではない文字列が存在し，また予約語が存在しない言語も存在する．この実験では，各言語のキーワードは予約語であると定義して実験を

Step γStep β で適用されたルールを Java で使用可能な正規表現に変換する．

Step δ

Step γ で変換された正規表現で，英字列を表しているものを選出する．

Step 

Step α で抽出されたリテラルと Step δ で選出された正規表現を全て結合して一つの表現にする．
図 8 は，予約語一覧の正規表現への変換例である．

3. 2. 2 で説明したコメントの場合と同様であるため，説明は省略する．

4. 評 価 実 験行った．
表 3 は，構文定義記述のファイル名と三つの情報を抽出可否を示したものである．○は抽出可能，×は抽出不可能を示し，「-」は構文定義記述に対応する記述がなかったことを示している．表 3 より，本研究で開発したモジュールではプログラミング言語の文法を表す 42 の構文定義記述のうち，コメントは 93%，予約語は 98%，文字列は 88%から抽出することができた．
もともと文法情報が定義されていないものも含めて，三つとも抽出できたものは 34 言語で，これは全体の81%にあたる．
本章では CCFinderSW を評価するために行った三つの実験について説明する．

4. 1 構文定義記述解析モジュールを用いた文法情報抽出実験
本研究で開発したモジュールを用いて，どの構文定
義記述からコメントと文字列リテラルと予約語の情報が抽出可能であるかを確認するための実験を行った．
実験の対象となるファイルは GitHub のリポジトリ
である grammars-v4（注 7）を使用した．このリポジトリ
は ANTLR の構文定義記述を集めたものであり，約150 種類が含まれている．ANTLR の開発者である
Parr も含めて，170 人以上の貢献者が存在し，現在でも更新が続けられている．実験で使用したリポジトリのスナップショットは 2017 年 12 月 14 日時点のものである．
本研究では，リポジトリに含まれている 154 種類の文法の中から，GitHub の Advanced Search（注 8）の検索対象に登録されている言語に対応する，構文定義記
述を実験対象とした．次に 42 の構文定義記述からコメント，文字列リテラル，予約語の三つの文法情報をあ（注 7）：https://github.com/antlr/grammars-v4（注 8）：https://github.com/search/advanced

本実験で抽出不可能となった構文定義の例について，
図 9 を用いて説明する．図 9 の左側は Lua.g4 におけるコメントを定義する字句解析ルールを表し，右側は生成されるコメントを例示したものである．この例のとおり，Lua.g4 のコメントは，開始時と終了時の ‘=’の数が同一であれば ‘=’ の数を変化させても成立す
る．一般的な正規表現は，文字の繰り返し数を記憶し，その後に出現する文字列の照合に用いることはできな
い [15]．そのため，開始時の ‘=’ の数を記憶し，終了時の ‘=’ の数が同一であるかを判定することが正規表現はできないため，抽出不可能とした．なお，CCFind-

erSW は 3. 2. 2 の Step B において，図 9 の COMMENTに対して NESTED_STR: ’[’ .*? ’]’ のみを適用した
記号列，及び NESTED_STR: ’=’ NESTED_STR ’=’ とNESTED_STR: ’[’ .*? ’]’ の両者を適用した記号列を生成し，ルールの適用を終了する．そのため，Step

C において ‘=’ の数が 0〜1 個の場合にのみ抽出できる正規表現が生成されるが，2 個以上のときは抽出できないため，本実験では抽出不可能とした．

4. 2 C++におけるコードクローン検出結果のCCFinderX との比較実験
本節では，C++で記述されたソースコードに対す
221電子情報通信学会論文誌 2020/4 Vol. J103–D No. 4
表 3 文法情報抽出実験の対象言語と実験結果
ファイル名 コメント
agc○
antlrv4○
apex○
asm6502○
aspectj○c○clojure○cobol85
○
cool
○
cpp14
○
csharp○css3○
ecmascript○erlang
○

予約語
○
○
○
○
○
○
○
○
○
○
○
×
○
○

文字列
○
○
○
○
○
○
○
○
○
×
○
○
○

ファイル名 コメント
fortran77○
golang
○
html
○
idl
○
java9
○
kotlin○lua
×modelica○
m2pim4○
objective-c○
pascal○phplexer
×
plsql○
prolog
-

予約語
○
○
○
○
○
○
○
○
○
○
○
○
-

文字列
○
○
○
○
×
○
○
○
○
○
×
○
×

ファイル名 コメント
protobuf3○
python3
○
r
○
rexx
×
scala
○
smalltalk○smtlibv2○
swift3○vba○
verilog2001○
vhdl○
visualbasic6○
webidl
○
xml
○

予約語
○
○
○
○
○
○
○
○
○
○
○
○
-

文字列
×
○
○
○
○
○
○
○
○
○
○
○
○
○

本実験の対象言語は，CCFinderX の対応言語の一つである C++を選択した．実験対象となるソースコー
ドとして，git（注 9）の master ブランチから 2018 年 12図9抽出不可能なコメントのルール

月 21 日 0 時 0 分時点でのスナップショットを取得した．
次に，CCFinderX と CCFinderSW に与えるオプ
ションについて説明する．共通のオプションとして検るコードクローン検出において，既存のコードクロー

出クローン片の最低字句数のしきい値を，大規模ソーン検出ツールである CCFinderX との検出結果の比較

スコードを対象とした場合に使用される 100（およそと分析を行う．この実験の目的は，CCFinderX が対

15〜20 行程度）にした [22]．CCFinderX では実用的応しているプログラミング言語において，CCFind-

なクローンを出力するために，メトリクスなどを用い

erSW が同様のコードクローン検出を行うことを示す

た様々なフィルタリングや，構文的な解析に基づく正ことにある．既存のコードクローン検出ツールの中規化を行っている．このため CCFinderX は，多言語から CCFinderX を比較対象として選択した理由は，に適用可能な字句分割と検出手法を用いる CCFind-

CCFinderSW と同様に字句単位の検出方法を採用し

erSW よりも少ない量のクローンペアを出力する．本ており，広く使用されている代表的なツールであるか

実験では，可能な限り CCFinderX と CCFinderSW

らである [20], [21]．

との検出条件を揃えるために，CCFinderX に与える

まず，実験の手順について説明する．同一のソー

三つのオプションを，デフォルトの値から変更した．

スコードに対して，CCFinderX と CCFinderSW で

まず P-match フィルタ（注 10）[23] をデフォルトでオン

コードクローン検出を行う．この際，二つのツールでのところをオフにした．また，クローン片に含まれる用いられるパラメータや条件は可能な限り揃える．次

最低字句種類数のしきい値をデフォルト値の 12 からに，それぞれのツールで検出されたクローンペアを比0 に変更し，Block Shaper（注 11）[24] に関するオプショ

較し，同一または類似したクローンペアが検出されてンをデフォルト値の 2 からを 0 に変更した．また，正いるかどうかを確認する．本研究では，二つのツール

確な比較を行うために，CCFinderSW を実行する前で検出されたクローンペア間の類似度が，しきい値以に CCFinderX が無視する初期化テーブルを対象ソー上であれば一致しているとみなす．特に同一であるとスコードから除去した．CCFinderX が初期化テーブみなされたものは完全一致と表現する．一致するものが存在しない場合，つまり片方のツールでしかクロー
ンペアが検出されていない場合は，もう片方のツールで検出されない原因を分析する．また，それぞれで検出されたクローンペア数と，マッチしたクローンペア
数について測定し，その割合を算出する．
222

（注 9）
：https://github.com/git/git（注 10）：クローンペア間で変数名が対応関係をもたない場合，そのク
ローンペアを除去するフィルタ．詳細は [23] 参照．
：ブロック単位のコードクローン以外を除去するフィルタ [24] を（注 11）
指す．Block Shaper オプションに 2 を設定するとブロック単位のコー
ドクローン以外を全て除去する動作になり，0 を設定するとフィルタが無効になり除去を行わない動作になる．

論文／多様なプログラミング言語に対応可能なコードクローン検出ツール CCFinderSW

ルを特定し検出対象か取り除く厳密なアルゴリズムについて，説明した文献やドキュメントが存在しないた

M atchB =MBlen ∗ 100
M ax(SWBlen, XBlen)

M atchSWX = M in(M atchA, M atchB)め，この前処理は著者が独自に実装した．

(8)
(9)

次に，検出されたクローンペアの比較方法の詳細と一致の定義について説明する．あるファイル A とファ

表 4 は実験の結果を示したものである．この表は，

イル B 間に存在するクローンペアについて，CCFind-

CCFinderX と CCFinderSW の検出クローンペア数，

erSW と CCFinderX で検出されたものを比較を行う

その二つのツールで検出されたクローンペアの一致とする．まずクローン片のそれぞれの名前についての数を表したものである．二つのツール間で完全一致

定義として，CCFinderSW で検出されたクローンペしたクローンペア数は 1806 個である．検出ペア中のアのクローン片を SWA と SWB として，CCFinderX

一致した割合は，一致した数を検出ペアの数で割っで検出された XA と XB とする．本研究で用いる手法

た値である．検出ペア中の一致した割合の列を見る

は行単位の一致率の計算を行う．比較するときに用いと，CCFinderX で検出されているクローンペアの約る数値としては，SWA と XA のそれぞれのクローン

98%が CCFinderSW で検出されており，逆も同様に

片の開始行と終了行，そして SWB と XB のそれぞれ

約 98%であることから，CCFinderSW は CCFinderXのクローン片の開始行と終了行となる．ここでそれぞとほぼ同等の検出能力をもっているといえる．

れのクローン片の開始行と終了行の値を start と end

次に，CCFinderX と CCFinderSW のそれぞれでを名前の後につけることで表現し，クローン片の長さ一致が見られなかったクローン片を目視で確認し，分を len をつけることで表現する．以上のことから，そ析した結果について述べる．まず，CCFinderX のみでれぞれのクローン片の長さは以下のような式となる．

検出された 32 個のクローンペアについて，CCFind-

erSW で検出されなかった五つの原因に説明する．各SWAlen = SWAend − SWAstart + 1(1)

SWBlen = SWBend − SWBstart + 1(2)

XAlen = XAend − XAstart + 1(3)（ 1 ） 何らかの理由で CCFinderX で検出されるク(4)

ローンペアが極大クローンペア（2. 参照）ではないた

XBlen = XBend − XBstart + 1

次に，このクローン片の一致率の計算式を説明する．

SWA と XA で一致している部を MA と表現し，ファイル B においても同様とする．このとき，MA の長さの定義を，与えられた二つの値で大きい側の値の返す
関数 Max と，与えられた二つの値で小さい側の値を返す Min を用いて，以下のように定義できる．MB に対しても同様の計算をする．

項目末尾に記載した括弧内の数値は，該当したクロー
ンペア数を表す．

め（16 個）．
（ 2 ） CCFinderX で検出されたコードクローンが，CCFinderSW での検出では字句数がしきい値の 100
より下回っていたため（8 個）．
（ 3 ） CCFinderX が，unsigned を含む型定義を一つの字句として認識しているため（4 個）．
（ 4 ） CCFinderX は，二項演算子 ‘+’ によりオペ
ランドの文字列の連結を行っている場合に一つの字句として認識する機能があるが，CCFinderSW ではそMAlen = M in(SWAend, XAend)− M ax(SWAstart, XAstart) + 1 (5)の機能がないため（2 個）．
（ 5 ） CCFinderSW で検出対象のソースコードに

MBlen = M in(SWBend, XBend)− M ax(SWBstart, XBstart) + 1 (6)次に SWA と XA の一致率を表す M atchA(%) を計行った前処理が誤っていたため（2 個）．
（ 2 ）の 現 象 が 生 じ た 理 由 は ，CCFinderSW と

CCFinderX 間で字句数の算出方法が異なるからで算し，ファイル B においても M atchB(%) を計算すある．CCFinderX は各言語ごとに手作業で字句解析る．最後に CCFinderSW と CCFinderX で検出され器を実装している．そのため，言語のよらず 3. 1. 2 のたクローンペアの一致率として，M atchSW X(%) をルールに基づき字句数の算出を行う CCFinderSW は，計算する．

CCFinderX とは字句数の算出結果が異なることがあ

M atchA =MAlen ∗ 100
M ax(SWAlen, XAlen)

る．また，全ての場合において 1 字句不足しているため，(7)検出できなかった．（ 3 ）の前処理は，CCFinderSW
223

電子情報通信学会論文誌 2020/4 Vol. J103–D No. 4
表4

CCFinderX との出力クローンペアの比較結果

CCFinderX
CCFinderSW

検出ペア
1928
1944

一致したペア
1896
1904

一致した割合
0.983
0.979

一致なし
32
40

を実行する前に CCFinderX が無視する初期化テーブに対しても，CCFinderSW を用いることでタイプ 2

ルを対象ソースコードから除去するために実施した．

のコードクローンが検出可能であることを示すために

しかし，CCFinderX よりも多くのコード片を初期化行った．

テーブルとして特定し，除去したことがあったため，上村らは，代表的な HDL である Verilog HDL の検出結果に差異が生じた．この原因は，CCFinderX

コードクローンの検出手法を提案し，10 件のプロジェが初期化テーブルを特定し検出対象か取り除く厳密なクト中のコードクローンについて調査している [25]．

アルゴリズムについて，説明した文献やドキュメント

この提案する検出手法は，Verilog HDL のソースコーが存在しないため，やむを得ずこの前処理を著者が独ドを幾つかの変換規則に基づいて疑似 C++に変換し，自に実装したことにある．この独自に実装した前処理

CCFinderX で変換後のソースコードを C++のソーにおいて，CCFinderX よりも多くのコード片を初期スコードとしてコードクローン検出を行うものである．

化テーブルとして特定し，除去した場合があった．

本研究における，提案ツールである CCFinderSW

次に CCFinderSW のみで検出された 40 個のクローの検出手法の評価に，上村らが用いたコードクローン

ンペアについて，CCFinderX で検出されなかった三検出ツールの評価手法を用いる [26]．コードクローン

つの原因に説明する．各項目末尾に記載した括弧内のの検出精度は，検出されたコードクローンのうち正解

数値は，該当したクローンペア数を表す．

の割合（Precision）と，全ての正解のうち検出できた（ 1 ） 何らかの理由で CCFinderX で検出されるク

コードクローンの割合（Recall）で評価することがでローンペアが極大クローンペア（2. 参照）ではないた

きる．Svajenko らは，自明なコードクローンを埋め込め（16 個）．

むことで正解集合を構築する手法を提案している [27]．

（ 2 ） CCFinderSW で検出されたコードクローン

この手法では，まずソースコード中から関数やコードが，CCFinderX での検出では字句数がしきい値の 100

ブロック単位でコード片を複数選択し，これに対してより下回っていたため（22 個）．

複数の変異を適用しソースコード中に埋め込んでいる．

（ 3 ） CCFinderSW で検出対象のソースコードに

そして，この変異コード片を文法上問題のない，ラン行った前処理が誤っていたため（2 個）．

ダムな位置に挿入し，自明なコードクローンを生成し，（ 2 ）の現象が生じた理由は，CCFinderSW で検出でき

正解コードクローンとして記録する．最後に，評価対なかった原因と同様に，CCFinderSW と CCFinderX

象のツールが，正解コードクローンを正しく検出でき

間で字句数の算出方法が異なることにある，また，（3）た割合を測定する．上村らは，Svajenko らが用いた変の誤りについても，CCFinderSW で検出できなかっ

異手法に幾つかの変更を加えて，Verilog HDL のソーた原因と同様に，やむを得ず著者が前処理を独自に実スコードに対するコードクローン検出の提案手法を評装したことにある．

価している．本実験では，上村らが用いたデータセッ

以上の実験と分析から，CCFinderX と CCFind-

トと同じものを用いた

erSW の検出能力はほぼ同等であると考えられる．検Svajlenko と Roy は，抽出するコード片の粒度を出結果に差異があったものに関しては目視で原因を突関数及びブロック単位とすると述べている．これにき止めることができた．

基づき上村らは module，always，if，case の 4 種

4. 3 Verilog HDL に対するコードクローン検出
精度に関する実験
本節では，Verilog HDL で記述されたソースコー

類のブロックを対象にしている．この評価対象には，Verilog HDL のプロジェクトの ridecore（注 12）が選ばれている．

ドに対して開発した CCFinderSW を用いてコードク

本研究では，上村らが作成した変異コードが埋め込

ローン検出を行い，その検出精度を評価する実験につまれたソースコードに対して，CCFinderSW を用いいて説明する．この実験は，CCFinderX などのコー
ドクローン検出ツールが一般的に対応していない言語
224（注 12）：https://github.com/ridecore/ridecore.git

論文／多様なプログラミング言語に対応可能なコードクローン検出ツール CCFinderSW
表5
(%)
タイプ 1
タイプ 2
総計

module100
100
100

Precision と Recall の測定結果

Precision
always
if
100
100
100
100
100
100

case
100
100
100

合計
100
100
100

module99
98
99

Recallalways
if
99
99
100
100
99
99

case
99
100
99

合計
99
99
99

てコードクローン検出を行い，Precision と Recall を去方式と識別子変換方式については，コメント除去及測定する．この際，CCFinderSW に与える構文定義

び識別子変換を行う他のコードクローン検出ツール

記述は，grammars-v4 の Verilog2001.g4 を使用してにおいても利用できる可能性があると考えられる．た検出を行った．Precision は，CCFinderSW によってだし，コードクローン検出ツールごとにトークン列や検出されたコードクローンのうち，誤検出ではないと

コードクローンの内部表現が異なることが多いため，判定された割合を表している．第一著者が手作業で検CCFinderSW のコメント除去及び識別子変換の実装を出されたコードクローンを確認し誤検出かどうか判定再利用することは容易ではないと考えられる．そのたした．このコードクローン検出では，CCFinderSW

め，他のコードクローン検出において，CCFinderSWの最低字句数をデフォルト値である 50 に設定したとのコメント除去変換及び識別子変換方式を実装する場

きに検出されたコードクローンを，クローン片に含合は，拡張元のトークン列やコードクローンの内部表

まれる字句種類数の最低しきい値を 12 としてフィル

現にあわせた実装を行う必要がある．

タリングを行ったものを対象とした．Recall は，変異コード片を用いて埋め込まれた正解コードクローンの6. む す び

うち検出されたものの割合を表している．上村らは，本研究では字句単位のコードクローン検出におけるmodule，always ブロックのコード片に対しては最字句解析に必要な文法情報を，構文解析器生成系の構

低字句数を 50（およそ 10 行程度），if，case ブロッ

文定義ファイルから自動的に抽出するモジュールを開発

クのコード片に対しては最低字句数を 25 としており，した．そしてこのモジュールを用いて，ANTLR の構本実験でもこの値を採用した．

文定義記述を入力として与えることで，対象言語の文本ツールで検出した結果の Precision と Recall を
表 5 に示す．総計はタイプ 1 とタイプ 2 を区別なく集法に沿ったコードクローン検出が可能な CCFinderSWを開発した．

計した結果である．本ツールの検出結果では，全体の構文定義記述解析モジュールの問題点として，構文

Precision は 100%，Recall は 99%となり，Precision

定義記述は対象となるプログラミング言語の文法に依が 99%，Recall が 93%の上村らの手法 [25] より高存するが，書き手にも依存する．つまり，同じ文法でい数値となった．Recall が 100%にならない理由は，

あっても複数の記述法で表現することができる．本研

CCFinderSW は識別子名は記号を含まないという前

究での開発は，構文定義記述の調査において多く存在

提で 3. 1. 2 で述べた字句分割を行うが，Verilog HDL

した記述法に対して行われたものである．新たに異なの変数名はグレーブアクセント（’）を含むことがでる記述法に対応するための，モジュールの拡張が必要きるからである．対象とした Verilog HDL のソースである．

コード中に，グレーブアクセントを含むため適切に正規化できなかった変数名が一つ存在した．識別子名に謝辞

文

記号が含むまれる前提で字句分割を行う方式に変更す
ることで解決できる可能性があるが，他言語のソース

を通して評価を行う必要がある．

5. 考

察

本ツールが構文定義記述に基づいて行うコメント除献[1]

井上克郎，神谷年洋，楠本真二，“コードクローン検出[2]法，” コンピュータソフトウェア，vol.18, no.5, pp.47–54,
2001.
肥後芳樹，神谷年洋，楠本真二，井上克郎，“コードク

コードに適用した際に正確な検出ができなくなる可能性があるため，どちらの方式が有効であるか比較実験

本 研 究 は JSPS 科 研 費 JP19K20240，

JP18H04094 の助成を受けた．

ローンを対象としたリファクタリング支援環境，” 信学論（D-I），vol.J88-D-I, no.2, pp.186–195, Feb. 2005.
[3] 肥後芳樹，楠本真二，井上克郎，“コードクローン検出とその関連技術，” 信学論（D），vol.J91-D, no.6, pp.1465–

225

電子情報通信学会論文誌 2020/4 Vol. J103–D No. 41481, June 2008.
[4]

[5]

Pragmatic Bookshelf, 2013.

Y. Semura, N. Yoshida, E. Choi, and K. Inoue, “Mul-[20]

tilingual detection of code clones using antlr grammarclone detection: A systematic review,” Information

definitions,” Proc. APSEC 2018, pp.673–677, 2018.

and Software Technology, vol.55, no.7, pp.1165–1199,

T. Kamiya, S. Kusumoto, and K. Inoue, “CCFinder:
A multilinguistic token-based code clone detection

2013.
[21]

system for large scale source code,” IEEE Trans.

of Computing, Queen’s University, 2007.

[6]

植田泰士，神谷年洋，楠本真二，井上克郎，“クローン検” 信学
出ツールを用いたソースコード分析ツールの試作，
技報，SS2001-14, 2001.

[7]

Y. Yamanaka, E. Choi, N. Yoshida, K. Inoue, and T.

[22]agement system,” Proc. IWSC 2012, pp.67–71, 2012.
K. Inoue, Y. Higo, N. Yoshida, E. Choi, S. Kusumoto,
K. Kim, W. Park, and E. Lee, “Experience of finding

May 2014.
[23]

inconsistently-changed bugs in code clones of mobile
Sakamoto,K.

Shimojo,R.

Takasawa,[24]

肥後芳樹，植田泰士，神谷年洋，楠本真二，井上克郎，“コードクローン解析に基づくリファクタリングの試み，”
情処学論，vol.45, no.5, pp.1357–1366, 2004.

[25]

K. Uemura, A. Mori, K. Fujiwara, E. Choi, and H.

work for developing test coverage measurement tools
supporting multiple programming languages,” Proc.
ICST 2013, pp.422–430, 2013.

Iida, “Detecting and analyzing code clones in HDL,”

C.K. Roy, J.R. Cordy, and R. Koschke, “Comparisonand evaluation of code clone detection techniques andProc. IWSC 2017, pp.1–7, 2017.
[26]

上村恭平，森 彰，藤原賢二，崔 恩瀞，飯田 元，“ハー”ドウェア記述言語におけるコードクローンの定量的調査，情処学論，vol.59, no.4, pp.1225–1239, 2018.

[27]

J. Svajlenko and C.K. Roy, “Evaluating modern clone

tools: A qualitative approach,” Science of Computer
Programming, vol.74, no.7, pp.470–495, 2009.
[11]

L. Jiang, G. Misherghi, Z. Su, and S. Glondu,“DECKARD: Scalable and accurate tree-based de-detection tools,” Proc. ICSME 2014, pp.321–330,

tection of code clones,” Proc. ICSE 2007, pp.96–105,

2014.

2007.
[12]

“On finding duplication and near-

1995, pp.86–95, 1995.
H.

Washizaki, and Y. Fukazawa, “OCCF: A frame-[10]

B.S. Baker,

duplication in large software systems,” Proc. WCRE

software,” Proc. IWSC 2012, pp.94–95, 2012.
K.

丸山勝久，沢田篤史，小林隆志，大森隆行，林 晋平，飯田元，吉田則裕，角田雅照，岩政幹人，今井健男，遠藤侑介，
村田由香里，位野木万里，白石 崇，長岡武志，林 千博，
吉村健太郎，大島敬志，三部良太，福地 豊，“産学連” 情処携によるソフトウェア進化パターン収集の試み，
学研報，vol.2014-SE-184/2014-EMB-33, no.1, pp.1–8,

Sano, “Industrial application of clone change man-

[9]

C.K. Roy and J.R. Cordy, “A survey on software
clone detection research,” Technical report, School

Softw. Eng., vol.28, no.7, pp.654–670, 2002.

[8]

D. Rattan, R. Bhatia, and M. Singh, “Software

H. Sajnani, V. Saini, J. Svajlenko, C.K. Roy, and（2019 年 6 月 7 日受付，10 月 2 日再受付，
12 月 5 日早期公開）

C.V. Lopes, “SourcererCC: Scaling code clone detection to big-code,” Proc. ICSE 2016, pp.1157–1168,
2016.
[13]

V. Saini, F. Farmahinifarahani, Y. Lu, P. Baldi, andC.V. Lopes, “Oreo: Detection of clones in the twilightzone,” Proc. ESEC/FSE 2018, pp.354–365, 2018.

[14]

G. Zhao and J. Huang, “DeepSim: Deep learning
code functional similarity,” Proc. ESEC/FSE 2018,
pp.141–151, 2018.

[15]

J.E. Friedl, Mastering regular expressions, O’Reilly

瀬村 雄一
平成 28 年度大阪大学基礎工学部情報科学科卒業，平成 30 年度大阪大学大阪大学
院情報科学研究科博士前期課程修了．現
在，日鉄ソリューションズ株式会社に勤務．
コードクローン検出に関する研究に従事．

Media, 2002.
[16]

瀬 村 雄 一 ，多 様 な プ ロ グ ラ ミ ン グ 言 語 に 対 応 可 能 な
コ ー ド ク ロ ー ン 検 出 ツ ー ル CCFinderSW，大 阪 大 学
大学院情報科学研究科 修士学位論文，（オンライン），
入 手 先 (http://sel.ist.osaka-u.ac.jp/lab-db/Mthesis/
contents.ja/146.html)，2019.

[17]

Y. Semura, N. Yoshida, E. Choi, and K. Inoue,“CCFinderSW: Clone detection tool with flexible multilingual tokenization,” Proc. APSEC 2017,
pp.654–659, 2017.

[18]

T. Parr, “About The ANTLR Parser Generator,”[19]

T. Parr, The definitive ANTLR 4 reference, The

http://www.antlr.org/about.html.

226

吉田 則裕

（正員）

平成 21 年大阪大学大学院情報科学研究科博士後期課程修了．同年日本学術振興会
特別研究員（PD）．平成 22 年奈良先端科
学技術大学院大学情報科学研究科助教．平成 26 年名古屋大学大学院情報科学研究科
附属組込みシステム研究センター准教授．
平成 29 年より同大学大学院情報学研究科附属組込みシステム
研究センター准教授（改組による）．博士（情報科学）．コード
クローン分析手法やリファクタリング支援手法に関する研究に従事．

論文／多様なプログラミング言語に対応可能なコードクローン検出ツール CCFinderSW

崔

恩瀞

（正員）

平成 27 年大阪大学大学院情報科学研究科博士後期課程修了．同年同大学大学院国際公共政策研究科助教．平成 28 年奈良先端科学技術大学院大学情報科学研究科助教．
平成 30 年より同大学先端科学技術研究科
助教（改組による）．平成 30 年より京都工芸繊維大学情報工学・人間科学系助教．博士（情報科学）．コー
ドクローン管理やリファクタリング支援手法に関する研究に
従事．

井上

克郎

（正員：フェロー）昭和 59 年大阪大学大学院基礎工学研究科博士後期課程修了（工学博士）．同年大阪大学基礎工学部情報工学科助手．昭和 59
年〜61 年，ハワイ大学マノア校コンピュー
タサイエンス学科助教授．平成 3 年大阪大学基礎工学部助教授．平成 7 年同学部教授．平成 14 年より大阪大学大学院情報科学研究科教授．ソフ
トウェア工学，特にコードクローンやコード検索などのプログ
ラム分析や再利用技術の研究に従事．

227