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

論

文

書き忘れたコードに対するコード補完について石原知也† a)

肥後芳樹† b)

楠本真二† c)On the Code Completion for Missing Middle CodeTomoya ISHIHARA†a) , Yoshiki HIGO†b) , and Shinji KUSUMOTO†c)

あらまし ソースコードの実装を支援する方法の一つとしてコード補完が挙げられる．近年，既存コードから収集した情報を利用してコード補完を行う手法が多数提案されている．これらの手法は書きかけのコードに続く
コードを補完できるが，書きかけのコードの途中に書き忘れがあった場合にそれらを補完できない．本論文では，そのような書き忘れが発生する頻度について調査した．また，書き忘れたコードも補完対象とすることでコード補完の機会がどの程度向上するのかについても調査した．これらの調査においては，被験者実験を行った．実験
では，被験者が行った計 51 タスクのうちの 41 タスクにおいて書き忘れが発生していた．また，その 41 タスクのうちの 10 タスクについては，既存コードから収集した情報を利用することにより書き忘れたコードに対して適切なコードを提示できることを示した．
キーワード

コード補完，コードクローン検出，ソースコード解析

1. ま え が き

変数名の補完や呼び出すメソッドの名前の補完（字句

コードの補完技術を利用することで効率的に必要なログラム文単位でのコード補完や必要なメソッド呼び

コードを実装できる．コードの補完とは，開発者が必出しの予測を行う．既存手法を用いることにより，よ要としているコードを，（半）自動的にエディタ上にり効率的に必要なコードを実装できる．しかし，既存

生成することである．コードの補完技術を利用するのコード補完手法は，書きかけのコードに書き忘れがことで，開発者は必要なコードを直接記述する必要あった場合に，その書き忘れたコードを補完できない．

単位での補完）であるのに対して，これらの手法はプがなくなる．現在では，コードの補完機能は Eclipse，

開発者は必要なコードを書き忘れてしまう場合がある

IntelliJ IDEA，Microsoft Visual Studio 等の統合開かもしれない．そのため，書き忘れたコードも補完対発環境では標準的に装備されており，多くの開発者が象にしたコードの補完機能を利用することで，より効

コードの補完機能を利用しているとの調査結果もあ

率的にコードの実装を行えると著者らは考えた．

る [1]．統合開発環境がもつコードの補完機能は比較的

本論文では，コードの書き忘れが発生する頻度を調単純であり，書きかけの変数名やメソッド名の補完や査した．また，書き忘れたコードに対してどの程度for 文等の制御構造のテンプレートを生成するのみでコード補完を行えるかを調査した（注 1）．これら二つのある．そのため，より有益なコード補完を実現するた

調査は，被験者実験によって行われた．各被験者にはめの研究が行われている [2]〜[12]．

コードを実装するタスクが与えられ，被験者がコード

統合開発環境に装備されている補完機能は利用するを実装する様子は画面を動画として撮影することにより記録した．被験者のタスクが全て終了した後に，著†者らがその動画を閲覧することによって調査を行った．

大阪大学大学院情報科学研究科，吹田市
Graduate School of Information Science and Technology,
Osaka University,

Yamadaoka 1–5,

その結果，全 51 タスクのうち 41 タスクにおいて書き

Suita-shi, 565–0871

Japana) E-mail: t-ishihr@ist.osaka-u.ac.jpb) E-mail: higo@ist.osaka-u.ac.jpc) E-mail: kusumoto@ist.osaka-u.ac.jp
DOI:10.14923/transinfj.2015JDP7086

電子情報通信学会論文誌（注 1）：本論文における二つの調査は，文献 [13] にて既発表である．しかし，文献 [13] では，調査方法の概要と大まかな実験結果を報告しているのみである．それに対して本論文では，調査方法の詳細な説明，実験結果の詳細な説明及びその考察，関連研究等についても記述している．

c 一般社団法人電子情報通信学会 2016
D Vol. J99–D No. 4 pp. 415–427 

415電子情報通信学会論文誌 2016/4 Vol. J99–D No. 4忘れが発生していた．また，全 51 タスクのうち 32 タ

左上隅の X 座標と Y 座標を取得するコードを記述しスクにおいて，既存コードから収集した情報を利用すている．次に開発者はこの四角形の右下隅の X 座標

ることで適切なコードを提示できることがわかった．

と Y 座標を取得し，それらを String 型に変換し，メ

また，それら 32 タスクのうちの 10 タスクでは書き忘

ソッドの返り値として指定するコードを記述しようとれたコードに対する適切なコードが存在していた．

している．このような状態において，もし開発者が既

本論文の主な貢献は以下の三つである．

•

被験者実験を行い，コードの書き忘れが実際に発生することを確認した．

•

書き忘れたコードも補完対象にすることによって，コード補完の機会が増えることを確認した．

•

本論文で考案した調査手法は，書きかけのメ

存のコード補完手法を利用すると，書きかけのコードに続くコード（図 1 (b) の吹き出し内のコード）が開発者に提示される．開発者は，提示されたコードが自分の意図したコードであれば，それを選択するのみでエディタ上にそれを反映させることができる．この例
では，右下隅の X 座標と Y 座標を取得するプログラ

ソッドを与えると自動的に補完候補となりうるプログ

ム文と，座標を String 型に変換しメソッドの返り値とラム文を検出する．そのため，書き忘れたコードに対して指定するプログラム文が補完され，これらを開発するコード補完手法の一部として利用可能である．し者が自分自身で記述する必要がなくなった．

かし，コード補完手法を完成させるためには，複数の書きかけのコードに続くコードだけではなく，書き候補が存在した場合のフィルタリングや順位付け等に忘れたコードも補完対象にすることによって，コードついても考案する必要がある．

補完はよりいっそう実装を支援できると著者らは考え

2. 準

備

本章ではまずこの研究の動機について述べ，そのあとに本論文で用いる用語を定義する．

た．例えば，Java の場合ではプログラムの実行時にNullPointerException が発生して，使用している変数に対して null かどうかのチェックを忘れていることに初めて気づく場合が多い [14]．図 1 (c) の上部の吹き2. 1 研究の動機

出し内のコードは，引数が null かどうかのチェックを

図 1 (a) は書きかけの Java メソッドである．このメしている．このように書き忘れたコードも補完対象とソッドにおいて，開発者は引数で与えられた四角形のすることによって，コード補完が実装に寄与する機会が向上すると期待できる．
以上のことから，本論文では，書き忘れたコードの補完に関連する以下の項目について調査を行う．
調査項目 1 どの程度の頻度でコードの書き忘れは発生するのか．
調査項目 2 書き忘れたコードも補完の対象にする
ことで，コードの補完が実装に寄与する機会はどの程度向上するのか．

2. 2 用語

ここでは，本論文で用いる用語の定義を行う．コードとは，一つ以上の連続するプログラム文を表す．書
き忘れたコードとは，実装済みのコードには存在していないがプログラムが正しく動作するためには必要なコードのうち，実装済みのコードよりも上部若しくは内部に挿入されるべきコードを指す．コード補完を行いたいメソッドを補完対象メソッドと呼ぶ．コード
補完手法によって開発者に提示されたプログラム文を補完候補，またその補完候補を提示する元となったメ
図 1 補完されるコードの例
Fig. 1 Example of completed code.

416

ソッドを補完候補元メソッドと呼ぶ．
これらの定義を図 1 に適用すると次のようになる．

論文／書き忘れたコードに対するコード補完について

図 2 図 1 に示す補完候補の補完候補元メソッド
Fig. 2 The method for suggesting candidate statements to the method in Fig. 1.

メソッド getRectCoords は補完対象メソッドである．

Fig. 3

図 1 (b) 及び図 1 (c) では，複数のプログラム文が開図 3 補完候補の有無を判定する方法の概要
Overview of the way we decide whether or
not there are candidate statements for a given
Java method.

発者に提示されている状態である．これらは補完候補である．図 2 に含まれるプログラム文が図 1 (b) 及び図 1 (c) において補完候補となっている．このときに図 2 に示すメソッドを補完候補元メソッドと呼ぶ．
図 1 (c) において，上部の吹き出しに含まれるコードは書き忘れたコードであるが，下部の吹き出しに含まれるコードは書き忘れたコードではない．
図 1 (a) と図 2 に示すように，補完対象メソッドに含まれている全てのプログラム文は，補完候補元メソッドにも含まれている．言い換えれば，補完候補元
メソッドと補完対象メソッドは Type-3 クローン（注 2）であるといえる．本論文では，補完候補元メソッドは補完対象メソッドの全てのプログラム文を含むことから，補完候補元メソッドは補完対象メソッドのスーパーク
ローンであるという．本論文の調査では，補完対象メ
ソッドのスーパークローンを検出することによって，書きかけのコードに対する補完候補の有無を判断する．

3. 補完候補の有無の自動判定方法
本論文の調査では，補完対象メソッドに対して，適切な補完候補の有無を判断した．補完候補の有無は
ソースコードを解析することにより自動的に行った．
補完候補が存在していた場合，それが適切かどうかの判断は著者らが目視により行った．
本章では，自動判定方法について説明する．この自動判定方法は，入力として補完対象メソッドを受け取り，そのメソッドのスーパークローンを出力する．
スーパークローンが存在していない場合はなにも出力しない．出力されたスーパークローンには存在してい（注 2）：Type-3 クローンとは，プログラム文単位での追加，削除，または変更を含んだクローンである [15]．

るが入力として与えたメソッドには存在していないプ
ログラム文が補完候補である．
この自動判定方法は，書きかけのコードに続くコー
ドと書き忘れたコードのどちらにも対応している．図 3
はその概要を表している．まずは，補完候補データ
ベースを構築する必要がある．データベースを構築するために，大量のソースファイルを入力として与える．
与えられたソースファイルは個別に解析され，その中に含まれているメソッドの情報が補完候補データベースに格納される．そして，補完対象メソッドが与えられると，データベースに格納されているメソッドとのスーパークローンを検出することにより，補完候補の有無を判定する．
この判定は二つの処理からなる．
処理 A

データベースの構築

処理 B

スーパークローンの検出

処理 A では，既存のソースファイル群に含まれる
各メソッドをプログラム文の列に変換する．各プログ
ラム文からはハッシュ値が計算される．ハッシュ値はデータベースに格納される．
処理 B では，補完対象メソッドがプログラム文の列に変換され，各プログラム文からはハッシュ値が計算される．次にその情報を用いてデータベースに問い合わせを行い，補完対象メソッドのスーパークローンを検出する．スーパークローンが検出された場合は，補完候補が存在していることを意味する．
以降，本章では，二つの処理について詳細に説明する．

3. 1 処理 A データベースの構築
図 4 は処理 A の概要を表している．この図に示す
417

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

switch 文の case エントリもこのカテゴリーに含まれる．
ブロック文 メソッド内において，ブロック（“{”と “}” で囲まれた範囲）をもつ文．例えば，if 文や for
文等が挙げられる．
シグネチャ文メソッドのシグネチャも文として扱う．Java 言語のシグネチャは，返り値の型，メソッド
名，仮引数で構成されている．
図 2 において，1 行目はシグネチャ文，2 行目はブ
ロック文，3〜4 行目は単文となる．
ステップ A2 プログラム文の正規化
このステップでは，各プログラム文に対して正規化を行う．正規化の対象は変数とリテラルである．正規化
処理として Parameterized Matching [16] を用いる．

Parameterized Matching は同じ変数は同じ文字列を置換に使用し，異なる変数に対しては異なる文字列をFig. 4図 4 処理 A の概要
Overview of method analysis.

用いて置換を行うという正規化方法である．例えば，
図 2 の 8 行目の文に対して Parameterized Matchingを適用すると，以下のように正規化される．

ように，メソッドを解析して補完候補データベースを構築する手順は次の三つのステップからなる．
ステップ A1 与えられたソースファイル群に含まれる各メソッドをプログラム文の並びに変換する．
ステップ A2 各プログラム文の中に含まれる変数
名及びリテラルを正規化する．
ステップ A3 各プログラム文の情報をデータベー
スに登録する．データベースに登録される情報は，プ
ログラム文のハッシュ値と正規化前後の字句の対応関係である．
以降，各ステップについて詳しく説明する．
ステップ A1 メソッドをプログラム文の並びへ変換与えられたソースファイル群から抽象構文木を構築

int x2=x1 + (int)rectangle.getWidth();↓ 正規化
int $0=$1 + (int)$2.getWidth();ステップ A3 プログラム文をデータベースへ登録
このステップでは，正規化された各プログラム文の以下の情報をデータベースに格納する．
ハッシュ値

ハッシュ値は，正規化後のプログラム

文の文字列に対して，MD5 アルゴリズムを適用する
ことによって計算される．
正規化前後の字句の対応関係 例えば，以下のプログラム文の正規化では，変数 a が$0 へ変換されたという情報と，リテラル 0 が$1 に変換されたという情することによってメソッドを抽出する．抽出したメソッ報がデータベースに格納される．

ドはプログラム文の並びへ変換される．抽出されたメ

int a = 0; → int $0 = $1;

ソッドは抽象構文木の部分木であるため，メソッドの中に含まれるプログラム文の特定は抽象構文木をたど3. 2 処理 B スーパークローンの検出ることによって簡単に行える．各プログラム文には固処理 B では，与えられた補完対象メソッドのスー

有の ID が割り振られる．この判定方法は Java 言語

パークローンを検出する．スーパークローンが検出さを対象としており，プログラム文を以下の 3 種類に分れた場合，与えられた補完対象メソッドに対して補完類する．

候補が存在していることになる．スーパークローンを

単文 セミコロン（“;”）で終了している文を指す．
例えば，変数宣言文や return 文が挙げられる．また，
418

検出する手順は次の三つのステップからなる．
ステップ B1 補完対象メソッドに含まれるプログ

論文／書き忘れたコードに対するコード補完について

図5

補完対象メソッド，スーパークローン，及びスーパークローンにならないメソッドの例（(b) から (e) は補完候補データベースに登録されているメソッドである）
Fig. 5 Example of target method for code completion, its super clone, and methods that are not regarded as super clones (methods from (b) to (e) arestored in complement candidate database).

ラム文からハッシュ値を計算する．そして，それら全れるメソッドの例を示している．この図において，プてのハッシュ値を含むメソッドをデータベースから取ログラム文の後のアルファベットは図 5 (a) と図 5 の得する．

他のメソッドとの対応関係を表すラベルである．もし，ステップ B2 補完対象メソッド内のプログラム文

開発者が図 5 (a) に示すメソッドを補完対象メソッドとデータベースから取得したメソッドに含まれるプロに指定すると，図 5 (b) に示すメソッドがスーパーク

グラム文をハッシュ値を用いて対応付けを行う．デー

ローンとして検出される．それ以外の三つのメソッド

タベースから取得したメソッドが下記のいずれかの条（図 5 (c), 5 (d) 及び 5 (e)）はスーパークローンになら件を満たす場合，そのメソッドは破棄される．

ない．

条件 A データベースから取得したメソッド内の

図 5 (c) は条件 A を満たすメソッドである．補完対プログラム文の並び順が，補完対象メソッドに含まれ象メソッド（図 5 (a)）の 5 行目及び 6 行目が，このるプログラム文の並び順と異なる．
条件 B データベースから取得したメソッド内のいずれかのプログラム文が，補完対象メソッド内の二つ以上のプログラム文と対応する．

メソッドの 7 行目及び 8 行目に対応するが，そのソースコード上での順番が入れ替わっている．よってこのメソッドはスーパークローンとして検出されない．
図 5 (d) は条件 B を満たすメソッドである．このメステップ B3 対応付けされたプログラム文においソッドの 3 行目が補完対象メソッドの 3 行目と 4 行目て，変数とリテラルの対応付けを行う．データベースの二つのプログラム文と対応している．よって，このから取得したメソッドが下記の条件を満たす場合，そメソッドもスーパークローンとして検出されない．

のメソッドは破棄される．
条件 C 変数やリテラルの対応付けに不整合が

図 5 (e) は条件 C を満たすメソッドである．このメ
ソッドの 3 行目，4 行目，及び 6 行目が，対象メソッ

生じる．

ドの 3 行目，4 行目，及び 5 行目と対応する．しかし，ステップ B3 を通過したメソッドが補完対象メソッド

これらのプログラム文には変数の対応関係において不のスーパークローンである．

整合が生じている．図 5 (a) では，5 行目のプログラ

図 5 はステップ B2 若しくはステップ B3 で破棄さム文の最後の変数は x であり，これは 3 行目のプログ419

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

ラム文で代入が行われている（ラベル B）．その一方

4. 1 実験の方法

で，図 5 (e) では，6 行目の最後の変数は b であり，こ本実験は以下の手順で行った．

れは 4 行目のプログラム文で代入が行われている（ラ手順 1 被験者は与えられた仕様に基づいて Javaベル C）．以上のことより，ラベル D のプログラム文のメソッドを実装した．被験者が実装している画面はは変数の対応関係に不整合が生じているために，スー

動画として録画された．

パークローンとして検出されない．

4. 実

験

2. 1 で示した二つの調査項目について回答するため，被験者参加型の実験を行った．この実験では，UCI（注 3）

手順 2 UCI データセットを利用して著者らが補完候補データベースを構築した．
手順 3 著者らは録画した動画を調査することによって，二つの調査項目に回答した．
手順 1 では，被験者は与えられた仕様に基づいてを利用して補完候補データベースをJava のメソッドを実装した．実装は画面を動画とし構築した．UCI データセットは Java で記述されたオーて録画する設定を行ったワークステーションにおいプンソースソフトウェアの集合であり，13,192 のプて行った．画面の録画には，CamStudio（注 4）というソ

データセット

ロジェクト，2,127,877 のソースファイル，20,449,986

フトウェアを利用した．そのワークステーションにはのメソッドが含まれている．

Windows Server 2008 R2 がインストールされてお調査項目に回答するためには，いつ書き忘れが発生したのかを特定する必要がある．本実験では，被験者

り，被験者はリモートデスクトップ接続でそのワーク
ステーションにログインした．

が実装済みのコードの間に新しくコードを記述した場

Java メソッドの実装において，著者らは被験者には合，その記述したコードを書き忘れたコードとした．

特に制限を課さなかった．被験者は普段通りに Java メ

図 6 は書き忘れたコードを示す例である．コードのソッドの実装を行った．また，被験者が実装したコー

左の数字は，記述された順番を表している．この例でドが仕様を満たしているかどうかを確認するために，は，3 番目に記述されたコード（引数の null チェック）

著者らはあらかじめ各タスクについてテストケースをは，1 番目と 2 番目に記述されたコードよりも，ソー準備した．被験者の実装した Java メソッドが用意さ

スコード上において上部にある．この場合は，3 番目

れた全てのテストケースを満たしたときに，著者らはに記述されたコードを書き忘れたコードとする．

被験者が与えられた仕様を満たす Java メソッドの実

なお，既に記述されたコードの一部が変更された場

装を終えたとみなした．

合には書き忘れコードとはしない．例えば図 6 におい

手順 2 では，著者らが 3. 1 で紹介した処理 A を実て，全てのコードが実装された後に 2 番目に記述され行してデータベースを構築した．データベースの構築たコードが修正された場合でも，そのコードは書き忘には約二時間を要した．

れコードにはならない．

手順 3 では，手順 1 で録画した動画を著者らが調査した．調査項目 1 へ回答するために，どのような順番でプログラム文が実装されていくのかを調査した．
また，調査項目 2 へ回答するために，動画の中の被験者の実装の手順を手元で再現した．そして，補完候補
データベースに問い合わせを行い，スーパークローンを検出した．検出されたスーパークローンを著者らが手作業で調査し，被験者の完成形のコードに含まれるプログラム文が存在しているかを判断した．存在していた場合には，適切な補完候補が存在していた，として扱った．この調査では，書きかけのコードを用いた

Fig. 6図 6 コードの記述順序の例
An example of code writing order.

（注 3）：http://www.ics.uci.edu/∼lopes/datasets/

420

データベースへの問い合わせを，被験者が新たにプログラム文を実装するたびに行った．
（注 4）：http://camstudio.org/

論文／書き忘れたコードに対するコード補完について
表 2 書き忘れたコードの種別と発生したタスクの数
Table 2 Categories of missing middle code and thenumber of tasks where such code occurred.
書き忘れたコードの種別発生したタスクの数
引数に対するエラー処理
25
オブジェクトの生成や初期化
19
処理結果に依存した処理の分岐
16
return 文を先に記述する習慣
5
入出力オブジェクトに対する close 処理
3
その他
12

えられたタスクの一覧を以下に示す．

T1 与えられたファイルパスから拡張子を除いたファイル名を取得する．

T2 与えられたファイルの中身をバイト配列に書き
図 7 被験者に与えられたタスク T2 のソースファイル
Fig. 7 Source file of task T2, which was passed toresearch participants.

込む．

T3 与えられた長方形の左上と右下の座標を取得
する．

表 1 書き忘れが発生したタスク（注 5）
Table 1 Tasks and participants where missing middle code occurred（注 6）.
P1
P2
P3
P4
P5
P6
P7
P8
P9
合計

T1
–
√

T3
√
√
√
√
√
√
√

T4
√
√
√
√
√
√
√
√
√

T5

–
√
√
√

T2
√
√
√
√
√
√
√
√

5

8

7

9

4

–
√

√
√
√
√

T6
√
√
√
√
√
√
√
√
8

合計
3
6
4
6
4
6
6
4
2
41

T4 与えられたバイト配列の一部をフィールドにあるバイト配列で置き換える．

T5 第一引数で与えられたファイルの中身を第二引数で与えられたファイルにコピーする．

T6 与えられた複数の文字列配列（char 型の配列）を連結し，CSV 形式で単一の文字列（String 型）に変換する．

4. 4 調査項目 1 への回答
表 1 は，どの被験者のどのタスクにおいて書き忘√れが発生したのかを表している．チェック（“ ”）は，

4. 2 被 験 者

その被験者のそのタスクにおいて書き忘れが発生した

本実験には九名の被験者に参加していただいた．1

ことを表している．ハイフン（“–”）は，そのタスク

名は博士研究員，2 名は博士課程の大学院生，6 名は修において動画の録画が失敗したため，書き忘れが発生

士課程の大学院生である．全ての被験者は，最低でもしたかどうかの調査ができなかったことを表す．全 54

半年の Java によるプログラミングの経験がある．被タスクのうち 3 タスクにおいて録画が失敗していた．

験者の Java プログラミングの経験は，大学の演習や

表 1 から，約 80%のタスク（51 タスク中の 41 タ自身の研究を遂行することによって得られた．

4. 3 タ ス ク
各被験者には六つのタスクが与えられた．被験者はタスクに記載されている仕様を満たすように Java のスク）において書き忘れが発生したことがわかる．また，全ての被験者は少なくとも二つのタスクにおいて書き忘れを発生させており，4 人の被験者は全てのタ
スクにおいて書き忘れを発生させていた．

メソッドを実装した．全てのタスクは単一の Java メ

著者らは，どのようなコードが書き忘れられていた

ソッドを実装するタスクであった．各タスクにおいて，のかについて調査を行った．表 2 はその結果をまとめ実装するメソッドのシグネチャと Javadoc コメントにている．一つのタスクにおいて複数の書き忘れが発生記載された仕様が被験者に与えられた．図 7 は，被験していた場合はそれらを個別に計上している．もっと者に与えられたタスクの例を表す．また，被験者に与も多かったのは，メソッドの引数が正常な値を保持しているかをチェックするコードであった．このような（注 5）：T はタスク，P は被験者を表す．
：T and P represent tasks and research participants, respec（注 6）

コードの書き忘れは 25 タスクで発生しており，書きtively.

忘れたコードが発生したタスクの 61%を占めていた．
421

電子情報通信学会論文誌 2016/4 Vol. J99–D No. 4
表 3 適切な補完候補が存在していたタスク（注 7）
Table 3 On which participant’s tasks the tool wasable to suggest appropriate candidates（注 8）.
P1
P2
P3
P4
P5
P6
P7
P8
P9
合計

T1
•◦
◦
◦
•◦
◦
◦
6

T2

T3
◦
•◦

◦
◦

T4
◦
•◦

T5
◦
◦
◦

•◦

•◦

◦

◦

◦

◦
4

◦
4

◦
5

4

T6
•◦
•◦
•
•◦
◦
◦
◦
◦
◦
9

合計
4
5
2
4
2
2
6
2
5
32

オブジェクトの生成や初期化のし忘れ，呼び出したメ
ソッドの返り値による処理の分岐漏れも発生していた．
五つのタスクでは，return 文を先に書いたことにより，書き忘れと判定されたコードも存在していた．この場
合は，return 文を先に記述することにより，Eclipse のエディタ上のコンパイルエラーを取り除くという意図があったと思われる．既存のコード補完手法を利用した場合には，return 文を先に書いてしまった場合は，その上部にコードを補完できないが，書き忘れたコードを考慮した補完手法では上部のコードを補完できる．
よって書き忘れたコードを考慮した場合にのみ補完でFig. 8図 8 適切なコードを提示できた例
Example of tasks where appropriate code wassuggested.

きるという状況という意味では，この場合も計上してよい．
以上のことから，調査項目 1 への回答は，約 80%のタスクにおいて書き忘れが発生した，となる．

32 タスク）において，適切な補完候補が存在していた．また，書き忘れが発生していた 41 タスクのうち

4. 5 調査項目 2 への回答の 10 タスクにおいて，書き忘れたコードに対する適表 3 は，どのタスクにおいて適切な補完候補が存

切な補完候補が存在していた．また，この表より，各在していたのかを示している．なお，構文的には完全被験者について少なくとも二つのタスクにおいて，適に同じではなくても，意味的に同じプログラム文を提切な補完候補が存在していたことがわかる．特に，被示できた場合には，提示できたとして計上した．構文験者 P7 については，全てのタスクにおいて適切な補的には同じではないが意味的には同じであった例とし完候補が存在していた．また，タスク T6 については，ては，“if(i - 1 > j)” がスーパークローンに含ま全ての被験者について適切な補完候補が存在していた．

れる補完候補であり，完成形のコードは “if(i > j +図 8 は書き忘れたコードに対する適切な補完候補1)” であったというものが挙げられる．表において，の例を表している．図 8 (a) は被験者が一つの変数宣白丸（“◦”）は書きかけのコードに続く適切な補完候言文を書いた状態を表している．また，図 8 (b) はそ

補が存在していたことを表し，黒丸 (“•”) は書き忘れの被験者の完成形のコードを表している．図 8 (c) はたコードに対する適切な補完候補が存在していたこと

図 8 (a) の状態のコードに対する補完候補を表していを表す．
この表より，約 63%のタスク（全 51 タスクのうちる．図 8 (b) と図 8 (c) を比べると，完成形のコードに含まれるプログラム文のうちの三つがスーパークローンに含まれていた．それら三つの補完候補は図 8 (c)（注 7）：白丸（“◦”）は書きかけのコードに続く補完候補を表し，黒丸（“•”）は書き忘れたコードに対する補完候補を表す．
：White circles (“◦”) and black circles (“•”) represent ap（注 8）
propriate following code and middle code were suggested, respectively.

422

では色付けして示されている．
幾つかのタスクにおいては適切な補完候補が存在していなかった．この原因は，被験者がデータセットに含まれているコードとは別の方法でタスクを実装した

論文／書き忘れたコードに対するコード補完についてためである．そのような場合でも完成したプログラム

ローンがソフトウェアの保守に悪影響を与えている理は正しく動作していた．

由は，ソースコードの異なる複数箇所を同時に変更す以上より，調査項目 2 への回答は，書き忘れが発生る必要があるからである．変更が必要な箇所を見落とした 41 のタスクのうち，10 のタスクにおいて適切なしてしまったり，誤った変更を加えたりした場合には，補完候補が存在していた，となる．

一貫性がないコードが発生してしまう [17]．

5. 議

論

以上のことから，補完候補の再利用によりソフト
ウェア間のコードクローンを増加させてしまうが，補

この章では，既存コードのプログラム文を再利用す

完候補データベースの構築に信頼性のあるソースコーることでコード補完を行うことについて議論する．まドを利用すれば，補完されたコードがそのソフトウェ

た，実験の妥当性についても述べる．

アの保守作業を妨げてしまう可能性は低い，と著者ら

5. 1 コード補完を用いる利点について
コードの補完を行うことにより，実装を行う際にさまざまな利点がある．第一の利点としてキータイプ数が減ることが挙げられる．キータイプ数を減らすことに特化したコード補完手法も存在する [4]．
第二の利点として，開発者が具体的なコードをイ
メージできていない場合でも支援できることが挙げらは考えている．

5. 3 実験の妥当性について
ここでは，本論文の実験の妥当性について述べる．
自動判定方法 本論文で紹介した自動判定手法では，再利用可能なプログラム文を含む全てのメソッドをスーパークローンとして検出できているわけではない．
検出できない理由として二つの理由がある．

れる．既存プログラムから抽出されたコードが開発者

一点目は，自動判定手法ではシグネチャ文からもに提示されるため，そのコードを閲覧することにより，ハッシュ値を生成しスーパークローンの検出に利用し実装したい機能がどのようなコードになるのかを把握ていることである．そのため，再利用可能なプログラ

できる．

ム文がシグネチャの異なるメソッド内に存在している第三の利点として，コードの品質確保につながるこ

場合には，そのメソッドはスーパークローンとして検とが挙げられる．例えば，開発者がテストを行って失出されない．しかしシグネチャ文も考慮することで，敗した場合に，コード補完機能を利用してテストを成メソッドのシグネチャのみを書いた状態で補完候補を功させるのに必要なコードを補完できれば，コードの探すことができるという利点もある．

品質がある程度確保されたことになる．

5. 2 補完候補の再利用によりコードクローンが発生する点について二点目は，メソッド内のプログラム文の並び順を過度に考慮している場合があることである．3. 2 で述べたように，スーパークローンの検出の際にはプログラ

補完候補を再利用した場合に，補完候補元メソッド

ム文の並び順を用いてフィルタリングを行っているが，と補完対象メソッドにおいて共通のプログラム文が発並び順が違っていてもスーパークローンとして検出す

生することになる．つまり，ソフトウェア間のコードべき場合がある．例えば，“int index = 0;” と “float

クローンが増加してしまう．コードクローンの存在は，

ratio = 0f;” のように，データ依存が存在しないプロ

ソフトウェアの保守を難しくする要因の一つといわれグラム文については並び順が違っていてもスーパークており，実際にコードクローンがソフトウェアの保守ローンとして検出しても問題ない．プログラム文間の作業を妨げた事例が報告されている [17]〜[19]．そのデータ依存を考慮することでより適切にスーパーク

一方で，保守に悪影響を与えるコードクローンは全体

ローンを検出することは可能である．本論文では，検の一部のみであるとも報告されている [20]〜[22]．

出の高速性を意識したためにデータ依存の情報は利用

悪影響を与えるコードクローンを開発者のソフトしなかった．

ウェアに作りこまないためには，データベースを構築

以上の二点が解決された自動判定法を用いた場合は，するために用いるソースコードが重要である．もし，本実験の結果よりも適切な補完候補が存在していたタ

データベースの構築に利用されたソースコードがよく

スク数が恐らく増える．

テストされたコードや長年の運用実績があるコードで被験者実験に参加した被験者は著者らと同じ研究ある場合は，開発者のソフトウェアに挿入されるコー室に所属する博士研究員と大学院生である．Java プ

ドはそのような信頼性の高いコードである．コードク

ログラミングの経験がより豊かなプログラマが被験者
423

電子情報通信学会論文誌 2016/4 Vol. J99–D No. 4だった場合は実験の結果が変わるかもしれない．本実験で確認できたことは，開発者が Java プログラミン
グの経験が半年以上程度であった場合は，適切な補完候補が存在していた，ということである．

6. 関 連 研 究
Hill らはメソッド単位でのコード補完手法を提案した [5]．この手法では，書きかけのメソッドを入力としタスク 実験で用いたタスクはどれも規模が小さく，て受け取り，そのメソッドから特徴ベクトルを生成す

一つのメソッドとして実装するものであった．一つのる．そして，あらかじめ収集しておいたメソッド群かタスクが複数のメソッドやクラスを実装することによら生成した特徴ベクトルと比較し，最も近い特徴ベク

り完成するような，より実用的なものであった場合は，トルをもつメソッドを，その書きかけのメソッドの完実験の結果が異なる可能性はある．しかし，一つのタ成形であるとして提示する．

スクの規模が大きくなった場合でも，メソッドを実装

山本らは，書きかけのコードに続くコードを補完すしていくということには変わりはない．よってより大る手法を提案した [10]．この手法では，収集したソー

きなタスクの場合でも，今回の実験と同様に多くの場

スコードに含まれる各メソッドを字句列に変形する．

合において適切な補完候補を提示できると著者らは考そして，各字句の区切りにおいて字句列を二分割し，えている．

前半の字句列をキー，後半の字句列をバリューとして，

この実験を行う際に著者らがデータセットに対してそのペアをデータベースに格納する．開発者が書きか事前に調査を行い，各タスクについて再利用可能な

けのコードに対してコード補完機能の呼び出しを行っ（注 9）

メソッドが少なくとも 1 種類は存在していることた場合は，その書きかけのコードがキー字句列としてを確認した．ここで再利用可能なメソッドとは，そのデータベースに問い合わせが行われる．そして，同じ

コードの一部若しくは全部を挿入するとタスクを完成

キー字句列をもつペアがデータベースに存在した場合させることができるメソッドを意味する．また，実験は，そのペアのバリュー字句列が書きかけのコードにの手順 3 を行った際に，全てのタスクに対して再利用

続くコードとして補完される．

可能なメソッドが少なくとも 2 種類は存在しており，

Han らは，開発者が短い入力を与えると，それをタスクによっては 10 種類以上のメソッドが存在してコンパイル可能なコードへと展開する手法を提案しいたことも確認できた．

ている [4]．例えば，開発者が “pv st nm” と入力する

書き忘れたコードが発生するのかどうかは被験者のと，この手法はそれを “private String name” と変換

実装に依存する．本実験では，著者らがタスクを作成する．このように，この提案手法を利用することで大した後に，被験者がそのタスクを Java メソッドとし幅にキータイプ数を減らすことができる．

て実装した．そのため，書き忘れたコードが発生する

また，メソッド呼び出しの補完手法も存在する．

タスクを著者らが意図的に作成したということはない

Bruch らはコード例を学習することによって書きかけことがいえる．

のメソッド呼び出しを補完する手法を提案した [2]．こデータセット

実験では UCI データセットを利用しの手法では，三つの補完戦略を利用している．一つ目て補完候補データベースを構築した．異なるソースの戦略は，収集したコードにおいて多く利用されてコードを利用してデータベースを構築した場合には，いるメソッド呼び出しが補完の候補として提示する．

提示される補完候補が異なるため，実験の結果が変わ

二つ目の戦略は，収集したコードにおけるメソッド呼る．また，5. 2 では，信頼性のあるコードを利用してび出しの並びの順を学習することにより，書きかけのデータベースを構築することが重要であると述べたが，コードにおいて次にどのメソッド呼び出しが必要かを

この実験では補完候補を提示できるかどうかについて予測する．三つ目の戦略は，k 近傍法を用いて，収集のみ調査している．この実験では補完されたコードのしたコードの中から書きかけのコードと似ているコー

信頼性については扱っていない．

ドを特定し，その特定したコードにおいて呼び出されているメソッド呼び出しを利用する．

Omar はコードの補完を支援するシステム Graphiteを開発した [8]．Graphite は色名と正規表現のコード（注 9）：ここで種類とは，コードが同じメソッドを表す．例えば，3 種
類のメソッドとは，コードが異なる（クローンになっていない）メソッ
ドが三つはあるという意味である．

424

補完を支援する際に，コードそのものを提示するのではなく，より開発者にわかりやすい形での補完を支援論文／書き忘れたコードに対するコード補完についてする．色名の場合は，色名を出すだけではなく，そのきないようなメソッド（例えば，図 5 (c)，5 (d)，5 (e)色を実際に表示し，開発者が選べるようにしている．

のメソッド）までクローンとして検出してしまう．そ正規表現については，正規表現内に存在する構文誤りのため，著者らはスーパークローンの検出において，の指摘機能や開発者が正規表現の振る舞いを調査する

既存の手法を利用しなかった．

ためのテストケース作成を支援する．

API の呼び出しパターンを抽出することによるコー

7. む す び

ドの補完支援も幾つか提案されている [3], [7], [12]．ラ

本論文では，書き忘れたコードの発生頻度（調査

イブラリの API には決まった呼び出しパターン（同項目 1）と，書き忘れたコードを考慮することによる時に使う API や API 呼び出しの順序）があることか

コード補完機会の向上（調査項目 2）について調査をら，既存コードから API がどのように呼び出されて行った．この調査では，九名の被験者が Java のコーいるのかを抽出し，その情報を用いて書きかけのコードを実装した．実装の様子は動画で撮影され，その動ドに対して補完を行う手法である．API 呼び出しの情画を著者らが閲覧することにより，調査項目 1 を調査

報を用いていることから，API 呼び出しを含むプログ

した．その結果，書き忘れは約 80%のタスク（51 タ

ラム文やそれらの文で利用されている変数を利用してスク中の 41 タスク）において発生しており，それらいる他のプログラム要素が補完の対象となる．

のうちの 24%のタスク（41 タスク中の 10 タスク）に

上記以外にもコードの補完手法は提案されているが [6], [9], [11]，これらは字句単位のコードの補完であ

おいて書き忘れたコードに対する適切な補完候補が存在していたことを示した．

り，プログラムの文単位で補完を行う手法ではない．

以上のことから書き忘れたコードを補完対象とする

統合開発環境には，実装を効率的に行うための支援ことでコード補完を行える機会が向上する．本論文で機能が装備されている．例えば，Eclipse には Quick

述べた調査手法は，書きかけのメソッドを与えると，

Fix という機能がある．Quick Fix には，さまざまな補完候補を含んだメソッドを自動的に検出する．そのプログラム要素に対して，幾つかの変更方法が定義さため，書き忘れたコードを対象とするコード補完手法

れている．例えば例外を投げるメソッドの呼び出しをの一部として利用することができる．しかし，コード含むプログラム文が try-catch 文で囲まれていない場

補完手法とするためには，複数の補完候補が存在した合にこの機能を使うと，そのプログラム文は try-catch

場合のフィルタリングや順位付けが必要である．今後部分で囲まれる．また，参照しているフィールドがはこれらについて研究を進めていきたい．

未定義であった場合にこの機能を使うと，その未定

謝辞 本研究は，日本学術振興会科学研究費補助金

義フィールドを作成する．このように Quick Fix は，基盤研究 (S)(課題番号：25220003)，挑戦的萌芽研究

ツールがさまざまな変更方法を定義するという支援方(課題番号：24650011)，及び文部科学省科学研究費補法である．一方，本研究で扱うコード補完は，データ

助金若手研究 (A)(課題番号：24680002) の助成を得てから補完候補を抽出する．そのため，データを用意で

行われた．
文

きればコード補完を行えるため，新しい変更方法の対応のためにツールを拡張する必要はない．

[1]

are Java software developers using the eclipse IDE?,”

本論文における判定方法は，Type-3 クローンの検出手法を含んでいる．Type-3 クローンの検出手法はこれ

献

G.C. Murphy, M. Kersten, and L. Findlater, “HowIEEE Softw., vol.23, no.4, pp.76–83, 2006.

[2]

M. Bruch, M. Monperrus, and M. Mezini, “Learn-

までにも多く研究がされている．有名なものとしては，

ing from examples to improve code completion sys-

Roy らが開発したクローン検出ツール Nicad が挙げら

tems,” Proc. 7th Joint Meeting of the European

れる [23]．このツールは，ソースコードに含まれる各Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software

ブロック（メソッドやその内部の for 文等）について，最長共通部分列を特定することによってクローンを検Engineering, pp.213–222, 2009.
[3]

API usage patterns by applying method categoriza-

出する．しきい値以上類似しているブロックのペアがtion to improve code completion,” IEICE Trans. Inf.

クローンとして検出される．しかしながらこの手法は，大規模ソースコードからの検出には長い時間を必要とする．また，この手法では，コードの補完には利用でR.J. Akbar, T. Omori, and K. Maruyama, “Mining& Syst., vol.E97-D, no.5, pp.1069–1083, May 2014.
[4]

S. Han, D.R. Wallace, and R.C. Miller, “Codecompletion from abbreviated input,” Proc. 2009425

電子情報通信学会論文誌 2016/4 Vol. J99–D No. 4
IEEE/ACM International Conference on Automated
[5]

[18]

K. Kim, W. Park, and E. Lee, “Experience of finding

R. Hill and J. Rideout, “Automatic method comple-

inconsistently-changed bugs in code clones of mobiletion,” Proc. 19th International Conference on Auto-software,” Proc. 6th International Workshop on Soft-mated Software Engineering, pp.228–235, 2004.
[6]

ware Clones, pp.94–95, 2012.

D. Hou and D.M. Pletcher, “Towards a better code

[19]

Finding Copy-Paste and Related Bugs in Large-Scale

popularity-based ranking,” Proc. 2nd International

Software Code,” IEEE Trans. Softw. Eng., vol.32,

Engineering, pp.26–30, 2010.
A.T. Nguyen,

T.T. Nguyen,

no.3, pp.176–192, 2006.
[20]

H.A. Nguyen,

A.

Nguyen, “Graph-based pattern-oriented, context-ence on Software Engineering, pp.311–320, 2011.
[21]

K. Hotta, Y. Sano, Y. Higo, and S. Kusumoto, “Issensitive source code completion,” Proc. 34th Inter-

duplicate code more frequently modified than non-national Conference on Software Engineering, pp.69–

duplicate code in software evolution?: An empirical79, 2012.

study on open source software,” Proc. Joint ERCIM

C. Omar, Y. Yoon, T.D. LaToza, and B.A. Myers,

Workshop on Software Evolution (EVOL) and Inter-“Active code completion,” Proc. 34th International

national Workshop on Principles of Software Evolu-

Conference on Software Engineering, pp.859–869,
2012.
[9]

N. Göde and R. Koschke, “Frequency and risks ofchanges to clones,” Proc. 33rd International Confer-Tamrawi, H.V. Nguyen, J. Al-Kofahi, and T.N.

[8]

Z. Li, S. Lu, S. Myagmar, and Y. Zhou, “CP-Miner:

completion system by API grouping, filtering, andWorkshop on Recommendation Systems for Software[7]

K. Inoue, Y. Higo, N. Yoshida, E. Choi, S. Kusumoto,

Software Engineering, pp.332–343, 2009.

tion (IWPSE), pp.73–82, 2010.
[22]

C.J. Kapser and M.W. Godfrey, “‘cloning considered

R. Robbes and M. Lanza, “Improving code comple-

harmful’ considered harmful: Patterns of cloning intion with program history,” Automated Software En-

software,” Empirical Software Engineering, vol.13,

gineering, vol.17, no.2, pp.181–212, 2010.

no.6, pp.645–692, 2008.

[10]

山本哲男，吉田則裕，肥後芳樹，“ソースコードコーパス

tection of near-miss intentional clones using flexi-[11]を利用したシームレスなソースコード再利用手法，” 情処
学論，vol.53, no.2, pp.644–652, 2012.
C. Zhang, J. Yang, Y. Zhang, J. Fan, J. Zhao, andP. Ou, “Automatic parameter recommendation for

hension, pp.172–181, 2008.

practical API usage,” Proc. 34th International Conference on Software Engineering, pp.826–836, 2012.
[12]

[23]

C.K. Roy and J.R. Cordy, “Nicad:

Accurate de-ble pretty-printing and code normalization,” Proc.
16th International Conference on Program Compre-（平成 27 年 9 月 4 日受付，11 月 24 日再受付，
12 月 29 日早期公開）

H. Zhong, T. Xie, L. Zhang, J. Pei, and H. Mei,
“MAPO: Mining and recommending API usage patterns,” Proc. 23rd European Conference on ECOOP
2009 — Object-Oriented Programming, pp.318–343,
2009.

[13]

石原 知也

T. Ishihara, Y. Higo, and S. Kusumoto, “How often
is necessary code missing? — A controlled experi-

平成 24 年大阪大学基礎工学部情報科学

ment,” Proc. 14th International Conference on Soft-科卒業．平成 26 年同大学大学院博士前期課程修了．在学時，コードクローン分析やコード補完に関する研究に従事．

ware Reuse, pp.156–163, 2015.
[14]

S. Kimura, K. Hotta, Y. Higo, H. Igaki, and S.
Kusumoto, “Does return null matter?,” Proc. International Conference on Software Maintenance,
Reengineering and Reverse Engineering, pp.244–253,
2014.

[15]

肥後 芳樹

E. Merlo, “Comparison and evaluation of clone detection tools,” IEEE Trans. Softw. Eng., vol.33, no.9,
pp.577–591, 2007.
[16]

B.S. Baker,“On finding duplication and near-

duplication in large software systems,” Proc. 2nd
Working Conference on Reverse Engineering, pp.86–
95, 1995.
[17]

肥後芳樹，楠本真二，“コード修正履歴情報を用いた修正漏” 情処学論，vol.54, no.5, pp.1686–1696,
れの自動検出，
2012.

426

（正員）

S. Bellon, R. Koschke, G. Antoniol, J. Krinke, and

平成 14 年大阪大学基礎工学部情報科学科中退．平 18 同大学大学院博士後期課程修了，平成 19 年同大学情報科学研究科助教．平成 27 年同准教授．博士 (情報科学)．
ソースコード分析，特にコードクローン分
析やリポジトリマイニング，リファクタリ
ング支援に関する研究に従事．情報処理学会，日本ソフトウェ
ア科学会，IEEE 各会員．

論文／書き忘れたコードに対するコード補完について

楠本

真二

（正員）

昭和 63 大阪大学基礎工学部卒業．平成3 年同代学大学院博士課程中退．同年同大

額基礎工学部助手．平成 8 年同講師．平成11 年同助教授．平成 14 同大学大学院情報科学研究科助教授．平成 17 年同教授．博士 (工学)．ソフトウェアの生産性や品質の定量的評価，プロジェクト管理に関する研究に従事．情報処理学会，IEEE，JFPUG 各会員．

427