発表の構成

1. コーディング中のリアクションを記録
2. ソースコードのコメント分析

1. やったこと

1. コーディング中のリアクションを記録するシステムを実装。
2. ソースコードから対応する表情を検索可能。
3. 表情の変化からソースコード中の難しい部分を検出可能か?

2. 背景

• ときどき「オレは一体何を考えてたんだ」というコードがある:

      int retval = -1;
      retval = doit();
      if (retval < 0) goto error; // WTF?
  error:
      return -1;
  

• コーディング中の独り言を録画しておきたい。
• ついでに動画も撮っちゃえばいいじゃん。

技術的な背景

• 「他人のコーディングを見る」という文化がある。
  YouTube / Twitch.tv  
• 多くの人が PC でカメラ・ヘッドセットを使っており、 フリーのデスクトップ録画ソフトウェアが利用可能。
  OBS Studio

3. 問題点

• プログラミングは何時間にもわたる。
• ソースコード中のどの文字がどの時点で書かれたのか不明。
• 数時間にわたる録音・録画から、該当部分を探すのは面倒。

解法 その1

• IDE / エディタを改造し、各文字ごとに変更履歴を記録する。
• 欠点: 改造が大変。ひとつの環境に固定されてしまう。

解法 その2 (提案手法)

• すべてのキー入力・その時刻を記録しておく。
• あとからソースのどの部分が対応するか計算する。

4. 実装上の問題

• テキストは通常、頻繁に削除・移動・複製される。
  ソースコード:

  int a=456123;
  

  実際のキー入力:
  b = 1 2 3 4 5 6 C-a i n t Space C-f C-h a C-e ; C-b C-b C-b C-b M-d M-b C-y
• 1対1対応は存在しない。

アルゴリズム

• 入力1: k_i ∈ K (キー入力、文字の順列)
• 入力2: t_j ∈ T (テキスト、文字の順列)
• 出力: M = {k_i → t_j}

観察

1. 順列 k_i および t_j がユニークならば、一意に対応するはず。
2. 連続したキー入力は、ソースコード上でも連続している。
3. 連続した「キー入力 = テキスト対」をクラスタリングしていけば、 そのうちユニークな順列ができあがる。

5. 実装

• Win32 用のキーロガーを作成。(C++)
• ログとソースコードの対応関係算出。(Python)
• ソースコードに対応した動画再生器。(HTML5/TypeScript)

  コード: https://github.com/euske/codecam/

6. 実験結果

1. Project Euler #89
2. 自作の HTML5ゲーム
3. Advent of Code 2017 - Day 19

• 適合率: 71% (まだ要追加実験)
• 再現率: 21% (コピペされた部分が多いため)

7. 表情を抽出する

• Microsoft Emotion APIを使用。
• 画像を入力すると、顔の位置および表情を認識:
  • happiness, anger, contempt, disgust, fear, sadness, surprise, neutral の 各確率を出す。
• 問題: ほとんどが neutral か happiness になってしまう。
  (サンプルの不足?)

8. デモ

9. 今後の課題

1. より精度を上げる。(コピペを記録する?)
2. より多くのプログラミングを記録する。
3. より多くの被験者を記録する。

10. 関連研究

• プログラム理解で伝統的な "Think aloud" 方式。
• コーディング中の視線トラッキング。
• コーディング中の脳血流トラッキング。
• 表情の認識。
• キーロガーの作成。

1. やったこと

1. ソースコード中のコメントのうち、プログラム理解に使えそうなものを分析した。
2. 自動抽出・解析手法を提案し、その精度を測定した。
   (コメント解析ツール「CommentVonComment」を作成)

2. 背景

• 新山の大目的: 「ソースコードからの意味抽出」
• ソースコードとラベル付データ (FGyama) の関連を学習。

  m = -1;
  for (i=0; i<n;
    if (m < a[i]
      m = a[i];
    }
  }       FGyama
  

• どうやって「ラベル」を取得する? → 変数名・コメントから

3. 関連研究

Tan, et al. "HotComments: How to Make Program Comments More Useful?", HOTOS 07

Linuxソースコードのコメントを分析し
"lock L must be obtained before entering F."
のようなパターンを見つけ、静的解析によりバグ発見。

Ying, et al. "Source code that talks: an exploration of Eclipse task comments and their implication to repository mining", MSR 05.

Eclipse中に含まれる "// TODO" コメントを人手で分析。

関連研究つづき

Steidl, et al. "Quality Analysis of Source Code Comments", ICPC 2013.

OSSプロジェクトから2,000ファイルのコメントを分類。
「コメント分類にはどんな種類があるか?」 「各カテゴリがどれくらい現れるか?」 「分類を自動化することは可能か?」

Pascarella and Bacchelli, "Classifying Code Comments in Java Open-source Software Systems" MSR 2017.

JavaおよびC++のコメントをそれぞれ830個と500個、手動で分類。 コメントの質を評価するための尺度を提案した:
coherence, usefulness, completeness および consistency.

4. Research Questions

• RQ1. 人々はコメントに何を書いているのか?
  1. コメントには構造があるのか
  2. それは(自動)分類が可能か
  3. 自然言語として文法的か
• RQ2. コードのふるまいを説明する表現はどんなものか?
• RQ3. 言語・プロジェクトによって差はあるか?

Motivating Example

1. // バッファはリトルエンディアン。
   x = (b[1] << 8) | b[0];
   

2. // バッファはリトルエンディアン。
   b[0] = x & 0xff;
   b[1] = (x >> 8) & 0xff;
   

コメントの「修飾する範囲」

1. 左側の構文要素を修飾 (L):

   int pos = 123;  // 最初の位置。
   

2. 右側の構文要素を修飾 (R):

   // ファイルを開く。
   reader = new FileReader(path);
   

3. ブロック全体を修飾 (U):

   while (p[i] < v) {  // まだ小さい。
     i++;
   }
   

5. データセット

• GitHub から★上位 1000個の Java プロジェクトを使用。
• 無作為に抽出したメソッド中のコメント1000個を人手で分類。
  1. コメント区切りを B/I/O 記法でタグづけ。
  2. 修飾範囲 (L/R/U)。
     L…92, R…704, U…75, 不明…129.
  3. コメントの分類 (後述)。
  4. (英文である場合) 文法的かどうか?

コメントの分類

• P (Postcondition - 実際の処理)

  // if we had a prior association,
  // restore and throw an exception
  if (previous != null) {
      ...
  

• A (Precondition - 前提条件)

  if (myStatusBar != null) { //not welcome screen
      myStatusBar.addProgress(this, myInfo);
  }
  

コメントの分類

• N (Nominal - 変数・値の説明)

  case 3: // INPUT_FORMAT
      return INPUT_FORMAT;
  

• C (Commented out - コメントアウト)

  } catch (CharacterCodingException e) {
       System.out.println(e);
       //e.printStackTrace();
  }
  

コメントの分類

• I (Instruction - TODO)

  //todo: move into ringbuffer.
  if (overflowPolicy == FAIL) {
      ...
  

• V (Visual cue - 見た目用)

  /* ---------------------------- */
  

コメントの分類

• D (Directive - コンパイラ用)

  //CHECKSTYLE:OFF
  } catch (final Exception ex) {
  //CHECKSTYLE:ON
  

• M (Metadata - 作者・ライセンスなど)

  // Took from http://stackoverflow.com/questions/
  // 8309354/
  final float scale = context.getResources()
    .getDisplayMetrics().density;
  

• U (Unknown - 不明)

分類した1000件中の内訳

分類基準はどれくらい妥当なのか?

1. 権藤先生と荒堀先生にも100件ずつ分類してもらう。(TODO)
2. どれくらい判断が一致しているかを測定。

6. コメント解析器の実装

1. コメント区切り B/I/O の自動判定。(C4.5, TODO)
2. コメント修飾範囲 L/R/U の自動判定。(C4.5, TODO)
3. コメント分類の自動判定。
   • 頻繁に現れる Postcondition と Precondition を なんとかして区別したい。

洞察

• ほとんどの Postcondition (処理内容) コメントは、 「命令形の動詞」または「If節」によって始まっている。
• 簡単な英語の構文解析を使えば判定できるのでは?
  • Stanford CoreNLP を利用し、constituent tree を分析する。
  • 精度を測定する。(TODO)

処理内容に頻出する英語動詞 Top 10

1. check (20)
2. be (19)
3. do (17)
4. create (15)
5. get (14)
6. ignore (13)
7. set (9)
8. remove (9)
9. make (9)
10. ensure (8)

7. 他の言語・プロジェクトへの適用

• 同一の判定規則を、他の言語 (C, Python) にも適用できないか? (TODO)
  • 精度の低下があるとしたら、言語のどのような特性によるものか?
• プロジェクトごとに頻出表現に差があるか? (TODO)

8. 結論

1. 従来あまり細かく分析されてこなかったコードの ふるまいに関するコメントを分析した。
2. コメントの「修飾範囲」という概念に着目した。
3. Precondition と Postcondition に着目した。
4. 実際の自然言語表現 (英語) に着目した。