研究進捗報告: 巨大プロジェクトにおける変数名の一貫性の検査

権藤研冬ゼミ資料 2019/12/27
新山

0. 夏ゼミ時との違い
1. 背景: 一貫性は巨大ソフトウェアプロジェクトを保守するのに重要である
2. 目標: ソースコード中の一貫しない変数名を指摘する
3. 理論: そもそも「一貫性 (consistency)」とは何か?
4. 準備: 変数の「データパス」に着目する
5. 手法: 学習と予測
6. 実験と評価方法
7. Discussion
8. 本論文の貢献

0. 夏ゼミ時との違い

基本的なテーマは同じ。
論文のプロトタイプとして議論を展開する。
実験結果を説明する。

1. 背景: 一貫性は巨大ソフトウェアプロジェクトを保守するのに重要である

巨大なプロジェクトは複数の人間からなるチームによって開発される。
- 1人の人間が長期間にわたって開発する場合も、時がたてば別の人間となる。
各参加者が協力しやすいように、ふつう何らかの指針 (ガイドライン) が決められる。
- ソースコードの「スタイルガイド」はよく知られている:
  - Google JavaScript Style Guide
  - NYTimes Objective-C スタイルガイド
- いっぽうで、識別子 (変数名・関数名) のガイドラインはあまり存在しない。 CamelCase / snake_case の使い分け程度。
  - Microsoft General Naming Conventions
だが、識別子はプログラム理解にとってきわめて重要:
- プログラマは名前の意味に頼っている。 [Lawrie, 06]
- 名前が悪いとプログラム理解の妨げになり、結果としてコード品質が下がる。 [Avidan, 17]
- 「このクラス・メソッドはどこで使われているのか?」は、プログラマが尋く頻度がもっとも高い質問。 [Sillito, 08]
- GitHub Issues で "wrong name" 等を検索すると、 100万以上の結果が返される。
- 名前の重要性は、書籍 ("Code Complete", "The Practice of Programming" 等) でも強調されている。

2. 目標: ソースコード中の一貫しない変数名を指摘する

void printResult(Stream out, String result) {
  out.writeLine("result:"+result);
}

void printStat(Stream out, int stat) {
  out.writeLine("stat:"+stat);
}

void printInfo(Stream strm, String info) {
  strm.writeLine("info:"+info);  // お前、ここはoutやろ。
}

2.1. 既存研究に対する立ち位置

識別子の問題に対処するために、これまで多くの試みがなされている。
- メソッド名の妥当性を検査する: [Høst, 09]
- コードからコメントを生成する: [Sridhara, 12]
- コードからメソッド名を提案する: [Allamanis, 15]
- 難読化されたJavaScriptコードからもとの変数名・型を推測する: [Raychev, 15]
- コードから単語ベクトルを抽出する (code2vec): [Alon, 18]

みんなメソッド名ばかりやっているが、変数名も重要だと思う。

変数名はおもにアプリケーションが扱う「モノ」の名前がつけられており、名詞である。

メソッド名に使われる動詞に比べると、名詞はずっと数が多く、アプリケーションの意味に関係が深い。

プロジェクト	名詞トップ5	動詞トップ5
ant (ビルドツール)	file, name, function, class, output	set, get, add, create, execute
antlr4 (構文解析)	string, rule, token, code, name	get, set, add, remove, visit
bcel (バイトコード解析)	constant, class, string, type, value	visit, get, accept, set, dump
compress (データ圧縮)	stream, entry, archive, data, input	get, set, read, write, close
jedit (テキストエディタ)	jj, action, line, string, buffer	get, set, add, run, remove
jhotdraw (図形描画)	action, figure, color, name, property	get, set, create, add, read
junit (ユニットテスト)	test, class, method, failure, runner	get, assert, run, test, validate
lucene (文書検索)	doc, next, string, value, bytes	get, set, compare, add, read
tomcat (Webサーバ)	name, string, session, max, class	get, set, add, remove, create
weka (機械学習)	text, tip, options, action, string	get, set, add, create, remove
xerces (XMLパーサ)	element, name, decl, type, impl	get, set, create, add, start
xz (データ圧縮)	stream, input, size, output, memory	get, write, read, close, set

既存研究をそのまま変数名に適用するのはあまり好きではない、なぜなら:
- 辞書やヒューリスティクスなどの外部的な制約をなるべく使いたくない。 (保守が大変 + バイアスを避けるため)
- 汎用のシステムを目指すのではなく、プロジェクトごとに調整可能なシステムを作るべき。
  なぜなら、識別子に使われている単語の意味はプロジェクトによって異なるから: (One size doesn't fit all.)
  - GUIアプリにおける "view"
  - SQLエンジンにおける "view"
  - 異なる略記法: message と msg など
- システムは、ブラックボックスによって得られた結果を提示するだけではだめで、ユーザ (プログラマ) がレビューできる論拠を示す (つまり、結果に対する説明責任を負う) べきである。

3. 理論: そもそも「一貫性 (consistency)」とは何か?

3.1. 一般論

A → B が予測される。この法則 (知識) を K としよう。
A が成り立っている。
B が成り立っていれば、「B は K に対して consistent である」
¬ B が成り立っていれば、「B は K に対して consistent でない」

例1.

K ≡ A → B: 「Aさんはマックに行くと必ずポテトを買う」
A: 「Aさんがマックに行った」
B: 「Aさんがポテトを買ってきた」 (一貫性あり)

例2.

A:「桜を見る会に反社会勢力などいない (7月)」 → B:「桜を見る会に反社会勢力などいない (12月)」
A:「桜を見る会に反社会勢力などいない (7月)」
B:「いたかも。でも誰も証明できんだろう (12月)」。 (一貫性なし)

3.2. プログラムの変数名に適用する

変数名の使い方に着目する:

A「ある変数が open() の返り値を受けとり、write() の第1引数に渡される」 → B「その変数名が out である」
```
out = open(...);
write(out, ...);
```
A「別の変数が open() の返り値を受けとり、write() の第1引数に渡される」
```
??? = open(...);
write(???, ...);
```
B: 変数名 ??? が out ならば一貫性あり。

3.3. ベイズ化する

一般には、ある規則がつねに 100% 成り立つということはあまりない。そこで、確率的に成り立つ規則を導入する。

A → B の成り立つ可能性が高い ≡ 確率 P(B | A) が高い。
P(B | A) が高く、なおかつ P(A) も高いにもかかわらず、 P(B) が低い → 一貫性なし。

4. 準備: 変数の「データパス」に着目する

ここでは、ある変数に代入される値が通る一連の処理 (または関数の引数および返り値が通るデータフロー) を、その変数の「使い方」と定義する。ここではこのデータフローを「データパス」と呼ぶ。

4.1. データパスの例

問. 以下の例で変数 line に着目する。

private BufferedReader fp;

public String get() {
    String line = fp.readLine();
    int i = line.indexOf(' ');
    return line.substring(0, i);
}

グラフ化するとこうなる:

グラフ中の赤線部分が変数 line のデータパスである:

fp.readLine() → line → #this:indexOf() → #arg1:substring()

これは、変数 line になにが代入され、それがどのように使われるかを示している。

4.2. Interprocedural 化する

private BufferedReader fp;

public String get() {
    String line = fp.readLine();
    int i = line.indexOf(' ');
    return line.substring(0, i);
}

public void show() {
    String name = get();
    System.out.println(name+"!!");
}

get() 中の変数 line (の処理結果) は、いまや show() 中では name となっていることに着目。

これをグラフ化するとこうなる:

最終的に、変数 line のデータパスは:

fp.readLine() → line → #this:indexOf() → #arg1:substring() → assign:name → L:+ → #arg0:println()

となる。この順列が、本プログラムにおける「変数 line の使われ方」を表すことになる。

単純化のため、いまのところパスの分岐は考慮しない。

5. 手法: 学習と予測

以上のようなデータパスを、プログラム中のすべての変数に対して (interprocedural で) 抽出し、変数名との相関を学習する。ここでは「データパスを与えると、変数名を予測する」ようなモデルを学習する。

たとえば、以下のようなデータパスが出てきたら:

fp.readLine() → ??? → #this:indexOf() → #arg1:substring() → assign:name → L:+ → #arg0:println()

ここでの ??? = line ではないか、と予測するということである。もしここで line 以外の名前が使われていたら、その変数名は (この使われ方に対しては) 一貫していない、ということになる。

具体的には、

すべての変数の集合を V とする。
For each v₁ ∈ V に対し、
1. 「v₁ を除いたすべての v ∈ V (v ≠ v₁)」に対して P(vの変数名 | vのデータパス) を求める。
2. argmax P(変数名 | v₁のデータパス) となるような変数名 n を求める。
3. n = v₁の変数名であれば一貫性がある。そうでなければ、n を変数 v₁ に対する「よりふさわしい名前」として提案する。
学習器には Naive Bayes classifier を使う。すべての変数に対して異なる母集団を使って P(名前 | データパス) を学習する必要があるが、 Naive Bayes における学習は単なる個数カウントなので、訓練データから特定のケースだけを「キャンセル」した学習結果が簡単につくれる。 (足した個数を引くだけ)
実際の素性は「名前」ではなく「名前を構成する単語の集合」である。
つまり、データパス → outputBufferName ではなく
- → output
- → buffer
- → name
(単語は CamelCase あるいは snake_case で区切られる)
実際の素性は「データパス」ではなく「パスを構成するエッジの集合」である。 (組み合わせ爆発を防ぐため)
例: #this:indexOf() → #arg1:substring() → assign:name というデータパスは、
- #this:indexOf() → #arg1:substring()
- #arg1:substring() → assign:name
という2つの素性に分解される。

6. 実験と評価方法

以下のプロジェクトに対して検証をおこなった: (実際には #エッジ < #データパス)

プロジェクト	KLOC	#変数	#ノード	#エッジ
ant (ビルドツール)	112k	23,971	350k	5,211k
antlr4 (構文解析)	31k	7,131	74k	1,103k
bcel (バイトコード解析)	31k	6,583	80k	1,190k
compress (データ圧縮)	24k	5,896	69k	929k
jedit (テキストエディタ)	115k	21,977	294k	6,106k
jhotdraw (図形描画)	80k	17,367	235k	2,351k
junit (ユニットテスト)	9k	2,384	21k	280k
lucene (文書検索)	109k	30,341	414k	7,146k
tomcat (Webサーバ)	238k	49,275	649k	11,799k
weka (機械学習)	324k	59,274	943k	13,224k
xerces (XMLパーサ)	114k	21,852	314k	7,017k
xz (データ圧縮)	7k	1,825	23k	299k

(疑問: 論文では数値の詳細を略すのは悪印象か?)

被験者: 著者3人 + 大学院生6人 = 計9人

RQ1. データパスは変数名の「使われ方」を表現するのに適切なのか?

まず予備実験として、データパスを本手法に使うことの妥当性を判断する。もしデータパスが変数名の「使われ方」をうまく表現できていれば、「同じデータパス」をもつ異なる変数は「同じ使われ方」をしているはずである。

実験1. データパスを使って同じ役割をもつ変数を判定する

各プロジェクトから同じデータパスの類似度が高い (cosine > 0.90) 変数の組を選び、(もとの変数名は隠して) それらが表れているコードを人間に見せて、同じ変数名にすべきかどうかを判定させる。

2つの変数名は同じであるべきだ。
2つの変数名は同じでもよい。
2つの変数名は違っているべきだ。
わからない。

全12プロジェクト × 各プロジェクト5問 × 9人 = 計540問の結果:

プロジェクト	#a	#b	#c	#d	#全体
ant	23	17	5	0	45
antlr4	13	22	9	1	45
bcel	3	11	31	0	45
compress	10	9	24	2	45
jedit	7	25	9	4	45
jhotdraw	15	17	12	1	45
junit	14	21	10	0	45
lucene	18	21	6	0	45
tomcat	11	27	6	1	45
weka	4	28	12	1	45
xerces	12	22	9	2	45
xz	4	15	26	0	45
計	134	235	159	12	540

#a + #b の割合が全体の 68% (369/540) を占めている。したがって、データパスが類似している変数は同じ名前をもつ可能性が高い。

なお、被験者は各組の cosine を知らされていないが、もともと 0.90 以上の対のみに絞ってしまったので、あまり blind test とは言えなくなくなってしまった。 (#a + #b の平均 cosine は 0.980, #c の平均 cosine は 0.976 である)

RQ2. うまく一貫性のある変数名を予測できたか?

実験2-1. 提案した名前がよいものかどうか判定する

For each 変数について、(名前は隠して) それが使われている部分を見せ

オリジナルの変数名
本手法によって提案された変数名
ベースライン手法によって提案された変数名 (型のみによって変数名を決定する、たとえば int型ならば変数名はつねに i)

の中から選ばせる (blind test)。なお、各プロジェクトごとに、提案されたスコアが高いものから 10個を選んだ。

全12プロジェクト × 各プロジェクト10問 × 9人 = 計1080問のうち、本手法の提案した変数名を選んだ人の割合は以下のようになる:

プロジェクト	#本手法	#全体
ant	39	90
antlr4	34	90
bcel	48	90
compress	53	90
jedit	24	90
jhotdraw	4	90
junit	34	90
lucene	40	90
tomcat	34	90
weka	29	90
xerces	31	90
xz	46	90
計	416 (39%)	1080

なお、9人の被験者による合意度 (Fleiss' Kappa) は 0.45 (Moderate) であった。

ちなみに、データパスから素性を生成するとき、異なるアルゴリズムを使った場合の実験結果は以下のようであった。

Methods	Interproc.	Name	Type	Length	%
5	+	+	+	5	39%
5	+	+	+	3	14%
5	+	+	+	1	7%
5	+	-	-	5	6%
5	+	+	-	5	10%
5	+	-	+	5	8%
5	-	+	+	5	10%
1	+	+	+	5	16%

また、各プロジェクトごとに生成された提案の数とそのスコア内訳は以下のようである:

プロジェクト	90%	80%	70%	60%	50%	40%	30%	20%	10%	0%	計
ant	2	15	61	144	302	637	1031	1985	3061	5784	13022
antlr4	7	9	41	74	144	217	344	453	658	965	2912
bcel	3	5	12	55	103	203	294	501	644	1042	2862
compress	4	6	16	45	98	214	276	504	822	1012	2997
jedit	7	14	58	199	345	606	965	1621	2349	3837	10001
jhotdraw	12	22	68	150	251	441	648	895	1284	1695	5466
junit	6	12	27	40	89	89	89	149	182	135	818
lucene	9	18	48	137	292	567	945	1735	2913	4546	11210
tomcat	13	42	112	264	544	1165	1729	3038	4897	8422	20226
weka	9	22	63	200	407	970	2054	3468	6905	10672	24770
xerces	5	27	49	131	289	435	756	1263	1924	3371	8250
xz	3	9	8	14	24	33	74	86	157	111	519

実験2-2. システムの出力をもとに各プロジェクト用の修正パッチを作成し、作者のもとに送る

各プロジェクトに対して計12個のパッチを作成。

Hello, we're developing an automated system that detects inconsistent variable names in a large software project. Our system checks if each variable name is consistent with other variables in the project in its usage pattern, and proposes correct candidates if inconsistency is detected. This is a part of academic research that we hope to publish soon, but as a part of the evaluation, we applied our systems to your projects and got a few interesting results. We carefully reviewed our system output and manually created a patch to correct a few variable names. We would be delighted if this patch is found to be useful. If you have a question or suggestion regarding this patch, we'd happily answer. Thank you.

3プロジェクトで採用された。
2プロジェクトで議論中。
1プロジェクトから「それほど優先度高くない」と返答。

RQ3. 変数名の予測には説得力があったか?

実験3-1. 提案した名前とその論拠を表示し、説得力があるかどうかを判定する

各プロジェクトごとに本手法で提案されたスコアが高いものから低いものまで 5個を選び、証拠とともに評価させる:

提案した名前を支持する確固たる説得力がある。
提案した名前がそれなりに正しそうな証拠である。
提案した名前が正しそうという確信はもてない。
わからない。

全12プロジェクト × 各プロジェクト5問 × 9人 = 計540問の結果:

プロジェクト	#a	#b	#c	#d	#全体
ant	7	8	30	0	45
antlr4	8	8	29	0	45
bcel	10	15	20	0	45
compress	5	5	34	1	45
jedit	6	6	33	0	45
jhotdraw	4	5	36	0	45
junit	2	7	36	0	45
lucene	3	14	27	1	45
tomcat	7	7	31	0	45
weka	1	10	34	0	45
xerces	6	10	28	1	45
xz	1	7	35	2	45
計	60	102	373	5	540

#a + #b の割合が全体の 30% (162/540) しかないが、以下に示すように、スコアが高い提案は #a + #b の評価になる割合が高く、スコアが低いものは #c になる割合が高い:

%score	#total	#a+#b	#c
> 80%	207	71 (34%)	133 (64%)
> 60%	108	40 (37%)	66 (61%)
> 40%	108	20 (19%)	88 (81%)
> 20%	108	24 (22%)	84 (78%)
> 0%	9	7 (78%)	2 (22%)

しかしこれは本手法によるスコアの妥当性を示しているにすぎず、全体としては論拠の有用性は示せなかった。 (そもそもどうすれば有用性を示せたのか、いまとなっては謎である)

Anecdotal Examples

Make the name more task oriented:

org/apache/bcel/Const.java:
-  public static short getNoOfOperands(final int index) {
-      return NO_OF_OPERANDS[index];
+  public static short getNoOfOperands(final int opcode) {
+      return NO_OF_OPERANDS[opcode];

Use the conventional abbreviation for the project.

gjt/sp/jedit/bsh/classpath/BshClassPath.java:
-	void errorWhileMapping( String s ) {
+	void errorWhileMapping( String msg ) {
...

org/apache/jasper/compiler/Generator.java
-            String pkgName = className.substring(0, lastIndex);
-            genPreamblePackage(pkgName);
+            String packageName = className.substring(0, lastIndex);
+            genPreamblePackage(packageName);

Use a synonym which aligns better with the other parts of the project.

org/apache/xerces/impl/xpath/regex/RegexParser.java
-        ReferencePosition(int n, int pos) {
+        ReferencePosition(int n, int offset) {

Correct typos:

src/org/tukaani/xz/lz/Hash234.java
-    void normalize(int normalizeOffset) {
-        LZEncoder.normalize(hash2Table, HASH_2_SIZE, normalizeOffset);
+    void normalize(int normalizationOffset) {
+        LZEncoder.normalize(hash2Table, HASH_2_SIZE, normalizationOffset);
...

7. Discussion

本実験の結果から…

データパスは変数の使われ方を表現するのにある程度有効。
実際のプロジェクトで、39% の確率でもとの開発者よりもよい名前を提案できた。
各提案で人間に納得できる論拠がきちんと示せたかどうかは証明できなかった。

7.1. Threats to Validity

Internal Validity (実験はRQに答えているか?)

被験者のプログラミング能力に左右されている。
→ しかし、もし被験者がランダムに選んでいるとしたら Kappa = 0 になるはずなので、被験者9人はある程度の一般的な基準を有しているといえる。
被験者が評価コードに対する前提知識があるかもしれない。
→ 今回のケースではない。
Precision のみで Recall が測定できていない。
→ 「完璧なソースコード」を取得することが不可能なので、 Recall は無理。

External Validity (一般化可能か?)

現状では、プログラミング言語は Java のみ。
実験プロジェクトおよび被験者の数が充分でない。
データパスの取得方法が完璧でない。 (実装上のミス、機能の欠損)
動的ディスパッチ、variable aliasing を全部追えていない。
データパス全体を比較せず、エッジを比較するだけの判定では不十分である。
Naive Bayes classifier の性能が不十分である。

8. 本論文の貢献

一貫性を検査するための一般的な枠組みを提案した。
変数の使い方を表現するためのデータパスという形式を提案した。
上の手法を使って、変数名の一貫性を検査・修正することができた。

よい論文とは?

重要な問題を扱っている。
主張および定義が明確である。
証拠が十分にある。

Yusuke Shinyama

Methods	Interproc.	Name	Type	Length	%
5	+	+	+	5	39%
5	+	+	+	3	14%
5	+	+	+	1	7%
5	+	-	-	5	6%
5	+	+	-	5	10%
5	+	-	+	5	8%
5	-	+	+	5	10%
1	+	+	+	5	16%

Methods	Interproc.	Name	Type	Length	%
5	+	+	+	5	39%
5	+	+	+	3	14%
5	+	+	+	1	7%
5	+	-	-	5	6%
5	+	+	-	5	10%
5	+	-	+	5	8%
5	-	+	+	5	10%
1	+	+	+	5	16%

Methods	Interproc.	Name	Type	Length	%
5	+	+	+	5	39%
5	+	+	+	3	14%
5	+	+	+	1	7%
5	+	-	-	5	6%
5	+	+	-	5	10%
5	+	-	+	5	8%
5	-	+	+	5	10%
1	+	+	+	5	16%