動詞に着目した相関ルールを利用するメソッド名の命名支援手法の評価

Presentation on theme: "動詞に着目した相関ルールを利用するメソッド名の命名支援手法の評価"— Presentation transcript:

1 動詞に着目した相関ルールを利用するメソッド名の命名支援手法の評価
○柏原 由紀1，石尾 隆1，井上 克郎1 1 大阪大学大学院情報科学研究科　コンピュータサイエンス専攻　 動詞に着目した相関ルールを利用するメソッド名の命名支援手法の評価について，大阪大学の柏原が発表いたします．

2 値を書き込むためのオブジェクトを取得する
背景 メソッド名が不適切だとプログラム理解に時間がかかる[1] 開発者は識別子の名前から動作を推測している 不適切な名前がついていると動作を誤解する setだから 値を設定している？ ・・・ まず，この研究の背景について説明します． javaプログラムにおいて，メソッド名が不適切だと，プログラム理解に時間がかかることが知られています． 開発者は識別子の名前からその動作を推測しているため，不適切な名前がついているとその動作を誤解してしまいます． 例えばこちらのコード片において，setBinaryStreamというメソッドを読んだとき，setは値を設定するメソッドによく使われる語なので，開発者は何かの値を設定するメソッドであるとその動作を予測します． しかし，実際の動作は値を書き込むためのオブジェクトを取得するメソッドであるため，その動作を誤解してしまいます． 実は 値を書き込むためのオブジェクトを取得する [1]Lawrie et.al. “What‘s in a name? a study of identfiers.”

3 メソッド名 メソッド名は動詞＋目的語の組で命名される 一部の動詞は具体的な使い方が知られている 他の動詞については使い方が知られていない
さまざまなプログラミングのガイドライン [2][3] 例：isEmpty, hasElement 一部の動詞は具体的な使い方が知られている 返り値がboolean なら is, hasなど Høstら[4]が40個の動詞の使い方を調査した “find”の動詞は「ローカル変数を使っている，かつ，ループを含んでいる」メソッドによく使われる　 他の動詞については使い方が知られていない 多くの単語から適切な動詞を選ぶ必要があり，難しい 一般に，メソッドはその動作と対象を動詞と目的語の組で表して命名されると，さまざまなプログラミングのガイドラインで言われています． 一部の動詞については，使い方がよく知られています．フィールドアクセスにget，setが使われることや，返り値がbooleanのとき，isやhasの動詞が使われるというものです． また，Hostらは上記の動詞を含めて40個の動詞について使い方を調査し，ルールとしてまとめています． しかし，これ以外の動詞について，一般にどのような語をどのようなメソッドに対して使うべきなのかということは具体的に知られていません． その中で開発者は命名のために多くの単語から適切な語を選ぶ必要があり，命名が難しいです． [2] Java Code Conventions，[3]Code Complete [4] Høst et.al. “The Programmer's Lexicon, Volume I: The Verbs”

4 我々の先行研究 開発者にメソッド名に用いる動詞の候補を提示する手法を提案 開発者が用いたときの影響を評価していない
既存のソフトウェアからメソッド本体とメソッド名の関係を表すルールを抽出する メソッド本体に出現する識別子の名前・型を利用 相関ルールマイニングを利用 抽出したルールを用いて対象のメソッドに対して動詞の候補を提示する 私たちは先行研究において，メソッド名に用いる動詞に着目し，開発者にメソッド名に用いる動詞の候補を提示する手法を提案しました． 既存のソフトウェアからメソッド本体とメソッド名の動詞の関係を表すルールを自動で抽出し， 抽出したルールを用いて，メソッドに対して適切だと考えられる可能性が高い順に動詞の候補リストを提示します． メソッド本体に出現する識別子の名前・型を，メソッド本体を表す要素として扱い， 相関ルールマイニングを利用してルールを抽出します． しかし，この手法では開発者に対する効果については評価していません． 開発者が用いたときの影響を評価していない

5 研究概要 開発者にメソッド名に用いる動詞の候補を提示する手法の改良した
開発者が実際に提案手法によって適切な動詞の候補を選択できるようになるのか評価した 被験者実験により評価 そこで本研究では，メソッド名に用いる動詞の候補リストを提示する手法の改良を行った上で， 改良した手法を用いて，実際に提案手法によって適切な動詞の候補を選択できるようになるのかを評価しました．

6 手法：概要 ①ルール抽出部 ②動詞推薦部 ルール バイトコード 対象のメソッド 動詞の候補リスト X → Y 要素 → 動詞
①ルール抽出部 　 X → Y 要素 → 動詞 ルール バイトコード 手法は，ルールを抽出するステップ1と，動詞の候補リストを提示するステップ2の2ステップから成ります． ステップ1について改良を行いました． 各ステップについて順に説明します． 対象のメソッド 動詞の候補リスト ②動詞推薦部

7 手法：概要 ①ルール抽出部 ②動詞推薦部 ルール バイトコード 対象のメソッド 動詞の候補リスト X → Y 要素 → 動詞
①ルール抽出部 　 X → Y 要素 → 動詞 ルール バイトコード まず，ステップ1について，変更点を比較しながら順に説明します． 対象のメソッド 動詞の候補リスト ②動詞推薦部

8 {返り値の型 : String[], 引数の型: String}
抽出するルール メソッド本体の内容を表す要素と，メソッド名の動詞の関係を表す相関ルール 条件部 帰結部 {メソッド本体の内容を表す要素} メソッド名の動詞 {返り値の型 : String[], 引数の型: String} split {呼び出しメソッド名の動詞: add} add 確信度： 条件部が出現するときにメソッド名に帰結部の動詞が使われる条件付き確率 支持度： ルールを満たすメソッドの数 リフト値： このルールのConfidece値が，単純な帰結部の出現率の何倍であるか ステップ1で抽出するルールは，メソッド本体の内容を表す要素と，メソッド名の動詞の関係を表す相関ルールです．ルールの左辺は条件部，右辺は帰結部といいます． メソッド内にある要素が出現するとき，ある動詞が使われやすいということを表します． 具体的なルールとして，返り値の型がStringの配列のとき，splitの動詞が使われやすいといったルールや，呼び出しメソッド名の動詞がaddのとき，そのメソッド名の動詞にもaddが使われやすいといったルールです． また，各ルールには，3つの評価値がついており， 確信度は，学習セット内における，条件部が出現するときに帰結部が出現する条件付き確率のことで， 支持度は学習セットの中でルールを満たすメソッドの数を表します， Lift値は，このルールの確信度が，単純な帰結部の出現率の何倍であるかを表しており， 帰結部の動詞が学習セット内で非常によく使われているときにLift値が低くなります．

9 メソッド本体の内容を表す要素 既存手法 メソッドに出現する単語・型 返り値の型 引数の型 呼び出しメソッド名 引数の名前
public class NameList implements Serializable{ LinkedList<String> nameList; int size; public String findName(int index){ if(index < 100 ){ if ( 0 <= index ){ return nameList.get(index); } printError(); return null; private void printError() { System.err.println("Error."); メソッドに出現する単語・型 返り値の型 引数の型 呼び出しメソッド名 引数の名前 (アクセスしている)フィールド名 既存手法では，メソッド本体の内容を表す要素は， 返り値の型，引数の型，呼び出しメソッド名，引数の名前，フィールド名の5種類を用いています． 例えば左のコード片のfindNameメソッドからメソッド本体の内容を表す要素を取得するとき， これらの要素がメソッド本体を表す要素として取得されます． これらの要素集合は，一つのメソッドから一意に取得でき， 各メソッドから要素集合を抽出し，相関ルールマイニングによりルールを抽出します． 返り値の型：　String 引数の名前 ： index　 呼び出しメソッド名　printError ・・・

10 メソッド本体の内容を表す要素 提案手法 メソッドに出現する単語・型 返り値の型 引数の型 呼び出しメソッド名の動詞
public class NameList implements Serializable{ LinkedList<String> nameList; int size; public String findName(int index){ if(index < 100 ){ if ( 0 <= index ){ return nameList.get(index); } printError(); return null; private void printError() { System.err.println("Error."); メソッドに出現する単語・型 返り値の型 引数の型 (アクセスしている)フィールドの型 呼び出しメソッド名の動詞 その他の語 アクセスしているフィールド名に使われる語 引数の名前に使われる語 呼び出しメソッド名の動詞以外の語 提案手法では，メソッド本体の内容を表す要素として， 返り値の型，引数の型，フィールドの型，呼び出しメソッド名の動詞，その他の語の5種類に分類した型や単語を用いるように改良を加えています． 既存手法で用いる要素にフィールドの型を追加し，呼び出しメソッド名，フィールド名，引数の名前を，単語に分解して，呼び出しメソッド名の動詞とその他の語として扱うようにします． たとえば左のコード片のfindNameメソッドからメソッド本体の内容を表す要素を取得するとき， これらの要素がメソッド本体を表す要素として取得されます． 返り値の型：　String その他の語：　error その他の語：　list 呼び出しメソッド名の動詞:　print ・・・

11 ルール抽出の際の条件 既存手法 動詞から始まるメソッドのみ学習に用いる 以下の条件を満たすルールのみを抽出する
get , set, testの動詞から始まるメソッドは除外 toString, equals, hashCodeメソッドは除外 以下の条件を満たすルールのみを抽出する 支持度が100以上のルール 条件部の要素数が4個以下のルール また，既存手法ではルール抽出においていくつかの制限を加えています． まず，学習に用いるメソッドとして，動詞から始まっているメソッドのみを用いています． ただし，get，set，testから始まるメソッドは使い方が既に知られているため， toString，equals，hashCodeメソッドは，javaの基底クラスであるObjectクラスに定義されており，オーバーライドしていることが多いため，学習セットから除外しています． さらに，有効なルールを抽出するために，100個以上のメソッドで使われているものを，また，オーバーフィッティングを避けるために条件部の要素数が4つ以下のものをルールとして抽出しています．

12 ルール抽出の際の条件 提案手法 動詞から始まるメソッドのみ学習に用いる 以下の条件を満たすルールのみを抽出する
get , set, testの動詞から始まるメソッドは除外 toString, equals, hashCodeメソッドは除外 以下の条件を満たすルールのみを抽出する 支持度が100以上のルール 条件部の要素数が4個以下のルール リフト値が1以上のルール 条件部が返り値の型：voidのみでないルール 提案手法ではさらに2つの条件を加えました． より意味のあるルールを抽出するためにLift値が1以上のルールを抽出し， また，返り値の型がvoidであることのみが条件部に出現するようなルールを排除するようにしました．

13 手法：概要 ①ルール抽出部 ②動詞推薦部 ルール バイトコード 対象のメソッド 動詞の候補リスト X → Y 要素 → 動詞
①ルール抽出部 　 X → Y 要素 → 動詞 ルール バイトコード このようにして抽出したルールを用いて，ステップ2でメソッド名の動詞の候補リストを提示します． ステップ2については，既存手法と同様です． 例を用いて説明します． 対象のメソッド 動詞の候補リスト ②動詞推薦部

14 共通：動詞の候補推薦 public boolean (int i) { return getField(); }
確信度 {返り値の型: boolean} is {引数の型: String, 返り値の型 : String[]} split {返り値の型: boolean, 呼び出しメソッド名の動詞: get} {呼び出しメソッド名の動詞: get} {返り値の型: boolean} is {引数の型: String, 返り値の型 : String[]} split {返り値の型: boolean, 呼び出しメソッド名の動詞: get} {呼び出しメソッド名の動詞: get} 0.4 0.5 0.6 1 2 0.2 ・・・・ public boolean (int i) { return getField(); } public boolean (int i) { return getField(); } 1 . is 2. split … スライド上部のルールを用いて，左下のメソッドに対して動詞の候補を提示します． まず，ルールのうち，条件をすべて満たすルールを選択します． このとき，帰結部に同じ動詞を持つルールがある場合，確信度が高いもののみを選択します． 選択したルールを確信度が高い順に順位をつけます． そして，この順位と同じ順番に帰結部の動詞を候補リストとして提示します． 開発者は提示されたリストを参考に，対象のメソッドの命名を行います．

15 評価実験 RQ1 RQ2 提案手法が，既存手法よりも適切な動詞を提示できるか 提示される候補リストは，開発者の適切な動詞選択を支援するか
この手法に対して，2つの観点から評価を行いました． 提案手法が，既存手法よりも適切な動詞を提示できるか， 提示される動詞の候補リストは，開発者の適切な動詞選択を支援するか という2点について評価しました．

16 RQ1. 既存手法より適切な動詞を提示できるか - 評価
方法 あるソフトウェア内の各メソッドの適切な動詞(既につけられている動詞)が候補リストの上位何番目に提示できているか 上位に提示できているほどよい 抽出したルール : 提案手法：2,947,148，　既存手法：304,770 112のOSS1(1,162,132個のメソッド)から学習 評価対象 学習に用いた112のOSS: 1,162,132個のメソッド 学習に用いていない4つのOSS: 13,563 個のメソッド Saxon-HE, Order Portal, NeoDatis， BlueJ public boolean isB(int i) { return getB(); } 1 . is 2. split … 手法が適切な動詞を提示できるかについては， それぞれの手法を，あるソフトウェア内のメソッドに適用し，既につけられている動詞が候補リストの上位何位に提示できているかを数えました． 既につけられている動詞をそのメソッドの適切な動詞とみなしており， 上位に正解を提示できているメソッドの数が多いほど適切な動詞を提示できている手法であると考えました． こちらのメソッドの例だと既につけられている動詞が1位に提示できているので，非常によいとみなします． 評価のために112のOSSプロジェクトから既存手法，提案手法それぞれを用いてルールの抽出を行いました． 既存手法では3万個，提案手法では300万個のルールを抽出しました． また，評価対象として，ルールの抽出に用いた112個のOSS，ルールの抽出に用いていない4つのOSSそれぞれに手法を適用して比較を行いました． 1. Qualitas Corpus

17 RQ1. 既存手法より適切な動詞を提示できるか - 結果
既存手法：39%のメソッドに対し上位5位以内に 提案手法：48%のメソッドに対し上位5位以内に提示できた 正解の動詞が提示されたメソッドの割合 提案手法： 学習に用いていないソフトウェア 提案手法： 学習セット 既存手法： 学習に用いていないソフトウェア 評価した結果を累積度数分布で表示した図です． 横軸は正解の動詞が提示されている順位，縦軸は正解の動詞が提示されたメソッドの割合を表しています． 例えば，この図のピンク色の線からは，提案手法を学習に用いていないソフトウェアに適用したとき，80%のメソッドに対して上位100位以内に適切な動詞を提示できていることを読み取ることができます． 結果として，学習に用いたソフトウェアに対しても，学習に用いていないソフトウェアに対しても， 提案手法を用いた場合の方が，既存手法と比べて，より上位に適切な動詞を提示できていることがわかりました． 既存手法： 学習セット 正解の動詞が提示されている順位

18 RQ2. 開発者の適切な動詞選択を支援するか – 評価
方法 既存のソースコードに定義されているメソッドから メソッド名などを削除 削除したメソッド名を被験者が推測し解答 評価基準 提案手法によって提示される候補リストの有無で 正解数に変化があるか比較 候補リストは上位5位を提示 開発者が適切な動詞を選択できるのかどうかについては， 被験者実験を行うことで評価を行いました． 既存のソースコードに定義されているメソッドからメソッド名を削除した課題を作成し， 被験者に削除したメソッド名を推測する課題を解いてもらいました． 提案手法によって提示される候補リストがある場合とない場合で正解数の差を分析しました． 候補リストは上位5つを提示します．

19 RQ2. 開発者の適切な動詞選択を支援するか - 課題となるメソッドの選択
課題となるメソッドを12個選択 4つのオープンソースソフトウェアから選択 RQ1と同じソフトウェア群 行数5行から15行のメソッドを選択 動詞一語で命名されているメソッドを選択 提案手法で正解が提示される順位を均等に 1位，3位，5位に正解があるもの， 　候補リスト内に正解がないもの：3つずつ 課題となるメソッド12個を4つのOSSから選択しました． 開発者の負担を考慮して5行から　15行のメソッドを， 目的語による影響を考慮して動詞一語で命名されているメソッドを課題として選択しました． 手法によって正解が提示される順位が均等になるようにメソッドを選択しました．

20 RQ2. 開発者の適切な動詞選択を支援するか -課題作成方法
public class AesMd5Cypher implements IO { public void write (byte b) throws IOException { try { byte[] bytes = {b}; write(bytes, 0, 1); } catch (IOException e) { DLogger.error(e.getMessage() + " - " + OdbThread.getCurrentThreadName()); throw e; } public class AesMd5Cypher implements IO { private String fileName; /** This method is ... */ public void write (byte b) throws IOException { try { byte[] bytes = {b}; write(bytes, 0, 1); } catch (IOException e) { // throw exeption DLogger.error(e.getMessage() + " - " + OdbThread.getCurrentThreadName()); throw e; } /** this method is … */ public long read(byte[] bytes,int offfset, int size) throws IOException { int totalread = 0; 　　 … 完成 対象メソッド内でアクセスされていないフィールドの定義を削除 メソッド内外のコメントを削除 対象のメソッド名を削除 (候補を提示する場合) write append add load create 対象以外のメソッドを削除 課題の作成方法について説明します． まず，対象のメソッドが記述されているjavaファイルを取得します． ここから対象以外のメソッドを削除します． 対象メソッド内でアクセスしていないフィールド，メソッド内外に記述されているコメントを削除します． 最後に，対象のメソッドの名前を削除します． 被験者はこの状態のメソッドを読んでメソッドの動作を推測します． 候補リストがある場合は，このように上位5位の動詞が提示されます． 課題を解いてもらう際，候補が提示された場合でも，リスト外から動詞を選ぶことができるとしています．

21 RQ2. 開発者の適切な動詞選択を支援するか - 被験者と課題の割り当て
情報科学を学んでいる学生12人 課題の割り当て 各課題を8人ずつに割り当てた 候補リストありで4人，なしで4人 各被験者に8問ずつ割り当てた 各被験者に候補リストありで4問，なしで4問 6人はリストありを先に，残り6人はリストなしを先に解答 被験者ごとに異なる順序 被験者は私の所属研究室の学生12人です． 課題の割り当て方については，各課題を8人ずつに解いてもらうように割り当てました． 候補リストがある状態で4人に，ない状態で4人に割り当てました． また，被験者一人につき，8つの課題を解いてもらうよう割り当てました． 被験者は8つの課題のうち，候補リストがある状態で4つ，ない状態で4つの課題を解くように割り当てました． 6人の被験者は候補リストありの課題4問を先に，残りの6人は候補リストなしの課題4問を先に解答してもらいました． また，同じ順序で課題を解く被験者がいないように割り当てました．

22 RQ2. 開発者が適切な動詞を選択できるか - 実際の実験アンケート
こちらが，実際に用いた実験課題の一部です． 1ﾍﾟｰｼﾞにつき1つの課題を提示しており， 課題のメソッドがあり，候補リストがある場合は，メソッドの下部に候補リストが提示されています． さらにその下部に，適切だと思う動詞と，その動詞を選んだ理由を記述する欄があります． このような課題が8つ，8ﾍﾟｰｼﾞ続き，最後のページには開発経験等を問うアンケートがあります．

23 RQ2. 開発者の適切な動詞選択を支援するか - 実験手順
実験の内訳 5分間の説明，課題の解答，アンケートの記入 被験者のみがいる部屋で実施 先に候補リストありで解く人と，先に候補リストなしで行う人で別々に実施 制限 制限時間は設けなかった 解答にかかった時間を測るため，カメラを設置 後戻りしての解答は許可しなかった 実験では，5分間の説明ののちに，課題の解答を行ってもらい，最後にアンケートの記入をしてもらった． 実験は被験者のみがいる部屋で実施し，先に候補リストがある課題から解く人と，さきに候補リストなしの課題から解く人で別々に実施しました． 解答時間について制限時間は設けませんでしたが，極端に速い回答もしくは遅い解答がなかったかどうか確認するために，カメラを設置して時間を計測しました． ページをめくってから次のページに移動するまでの時間をその課題にかかった時間としました． また，一度解いた課題の解答を修正する等の後戻りは許可しませんでした．

24 RQ2. 開発者の適切な動詞選択を支援するか - 結果
候補リストの有無による正解・不正解の解答数 正解 不正解 合計 候補リストあり 28 20 48 候補リストなし 25 23 53 43 96 カイ二乗検定(片側検定) 候補リストがあるときの方が正解数が有意に多いか p = 0.43 より　有意水準α =0.05で　有意差なし 被験者に課題を解答してもらった正解率を表に示します． 結果として，候補リストがある状態で解いてもらった48問のうち28問が正解， 候補リストが無い状態で解いてもらった48問のうち25問が正解となりました． 候補リストがある場合の方が，正解数が多い結果となったものの， カイ二乗検定を行ったところ，有意水準0.05で正解数の差は有意でないことがわかりました．

25 候補リスト内に正解が含まれている順位ごとに正解数が異なるか
候補リストを提示したときに， 正解が提示されている順位ごとの正解・不正解の正解数 候補リストあり 候補リストなし 1位に正解 11/12 10/12 3位に正解 8/12 4/12 5位に正解 7/12 候補リスト内に正解なし 2/12 さらに詳しく分析を行いました． 候補リスト内に正解が含まれている順位ごとに正解数をみると， 候補リスト内に正解が提示されているとき正解率が高いことがわかりました． 候補リスト内に正解がない場合に特に正解数が低かった課題について解答の仕方を分析したところ， 常に候補リストの中から選んで間違っているのではないことがわかりました． 候補リスト内に正解が提示されているとき，候補リストがある方が正解数が多い 常にリスト内から解答が選ばれているわけではない

26 候補リスト内に正解が含まれているときに正解数が多いか
候補リスト内に正解が含まれている課題における， 候補リストの有無による正解・不正解の解答数 正解 不正解 合計 候補リストあり 26 10 36 候補リストなし 18 44 28 72 フィッシャーの正確確率検定(片側検定) 候補リストがあるときの方が正解数が有意に多いか p = より　有意水準α =0.05で　有意差あり 候補リスト内に正解が含まれているとき，有意に正解数が多いかどうかをフィッシャーの正確確率検定を用いて検定を行ったところ，有意水準0.05で有意差があるということがわかりました．

27 考察 候補リストがあるだけでは全体での有意差なし 候補リスト内に正解がある場合，正解数が有意に高い
候補リスト内に正解を含めていれば，開発者が適切な動詞を選択する手助けになる 候補リストを提示する手法の精度を高める必要がある 候補リストがある場合全体では正解数は有意に多くなく， 候補リスト内に正解がある場合に正解数が有意に高いことから， 候補リスト内に正解が含まれていれば開発者が適切な動詞を選択する助けになると考えられます． 従って，候補リストを提示する手法の精度は，今のままでは不十分であり，精度を高める必要があると考えられます．

28 まとめと今後の課題 まとめ 今後の課題 メソッド命名の支援のためのメソッド名に用いる動詞の候補リストを提示する手法を改良した
既存手法よりも上位に正解を提示できていることを示した 候補リスト内に正解が含まれているとき，正解率が高いことを示した 今後の課題 手法の改善 標本数を増やして再評価 まとめと今後の課題です． 本研究では，メソッド命名の支援を行うために，メソッド名に用いる動詞の候補リストを提示する手法を提案しました． 学習に用いていないソフトウェアに適用したとき，48%のメソッドに対して上位5位以内に正解を提示できたことを確認しました． また，被験者実験を行い，候補リスト内に正解が含まれているとき，正解率が有意に高いことをしめしました　． 今後の課題として， 候補の提示手法を改善することや，被験者実験における標本数を増やして再度実験を行うことが考えられます． 以上です．

29 以下非表示スライド

30 候補リストありのときの方が 正解が少なかった例：reset
public abstract class Builder implements Receiver { protected String systemId; protected String baseURI; protected NodeInfo currentRoot; protected boolean lineNumbering = false; protected boolean started = false; protected boolean timing = false; protected boolean open = false; public void reset() { systemId = null; baseURI = null; currentRoot = null; lineNumbering = false; started = false; timing = false; open = false; } 候補リストあり end init initialize 候補リストなし reset start enter leave write end

31 候補リストありのときの方が 正解が少なかった例：update
public class ProductGroupController extends AbstractController { private static final String PATH_UPDATE = BASE_PATH + "/updateProductGroup.jsp"; private void update() { try { openConnection(); processUpdate(); commit(); refreshMenu(); forward(PATH_UPDATE); } catch (Exception e) { doCatch(e); } finally { finallyMethod(); } 候補リストあり commit update refresh 候補リストなし commit process refresh do execute

32 候補リストありのときの方が 正解が多かった例：find
public class JdiThreadSet extends HashSet<JdiThread> { public JdiThread find(ThreadReference thread)　{ for(Iterator<JdiThread> it=iterator(); it.hasNext(); ) { JdiThread currentThread = (JdiThread)it.next(); if(currentThread.getRemoteThread().equals(thread)) { return currentThread; } Debug.reportError("Encountered thread not in ThreadSet!"); return null; 候補リストあり find 候補リストなし update get report is translate parse find

33 候補リストありのときの方が 正解が多かった例：print
public abstract class CallableView extends MemberView { public void print(FormattedPrintWriter out, int indents){ Comment comment = getComment(); if(comment != null) comment.print(out, indents); out.setItalic(false); out.setBold(true); for(int i=0; i<indents; i++) out.indentLine(); out.println(getLongDesc()); } 候補リストあり print write 候補リストなし set display output write visit print