キャメルケースはスネークケースよりも読みやすい説

プログラムの識別子として複数の英単語をつなげるとき、単語区切りを大文字にしてつなげる CamelCase と、アンダースコアを使ってつなげる sanke_case の2つが良く使われています。この2つのどちらが読みやすいのか実験をした人がいる、というのが意外と知られていない気がしたので、ちょっと紹介しておきます。

To camelcase or under_score - IEEE Conference Publication (著者が配布している版はこちら)

この論文は被験者実験を行っています。 "extend alias table" のようなフレーズの後に、それを識別子に変換したもの（キャメルケースの場合 "extendAliasTable" ）と単語のうち1つを偽物に入れ替えたもの（この例の場合 expandAliasTable, extendAlistTable, extendAliasTitle）を表示して、その中から正解を選ぶというタスクにおいて、被験者が目的のフレーズに当たる識別子を正確に、早く認識できるかを調査しています。

基本は統計的に有意な差が出るかどうかの判定をしていて、結果は以下の通りでした。

• 認識の正確さはキャメルケースのほうが高い（オッズ比 1.515）。
• キャメルケースのほうが認識に少し時間がかかる（13.5％、実時間にして0.42秒）。
• トレーニングが正確さに影響するかは分からない（帰無仮説が棄却できない）。
• トレーニングで認識にかかる時間は短くなる。

この論文では2つを比べるという都合上、キャメルケースのほうが良いという結論になっています。ただし、この実験設定はけっこう意地悪でもあって、似たような識別子がたくさん並ぶ状況ならば省略表記のほうが読みやすいという指摘もあります。関連研究のところにそういうこともしっかり書いてあるので、論文の著者らもキャメルケースを本気で押そうと思っているわけではなさそうです。

認識時間にほとんど差がなく、トレーニングで認識にかかる時間が短くなるということから、使い慣れたほうを使うほうが早いという常識的な話とも言えてしまいますが、この論文は「読みやすさ」というあいまいな指標を正確さと時間に分解して計測するという実験の作り方として参考になりますし、この研究から視線計測に基づく視認性の調査などにも続いていますから、ソフトウェア工学の中でもプログラム理解という分野を学ぶ上では良い材料であると思います。

 [2019/4/17 追記] この記事を書いた後に気づいたのですが、プログラム理解に関する国際会議（ICPC 2019）の開催情報によると、この論文がちょうど10年前に発表された論文の中から最も影響の大きかった論文（Most Influential Paper）に選ばれたようです。

スマートフォンを支えるオープンソースソフトウェア

IPSJ-ONE にて、「ソフトウェアの生態系を探る」というタイトルで登壇してきました。

ipsj-one.org

この発表では時間の都合上、まったく言及することができませんでしたが、「ソフトウェアの生態系（Software Ecosystem）」と総称されるオープンソースソフトウェア群は日常生活に非常に密接にかかわっています。

私たちにとって身近で、かつ、オープンソースソフトウェアを活用している筆頭と言えそうなのが Android プロジェクトです。Android SDK のソースコードをダウンロードしてくると、2019年2月時点で、external ディレクトリに300個ぐらいのソフトウェアが並びます。この中には、たとえば以下のようなものが入っています。

• 1979年に発表された Basic Linear Algebra Subprograms に由来するベクトルや行列を扱うライブラリ。OpenCV なんかも同じ仲間と言ってよいかもしれません。
• 1984年頃からインターネットの発展に伴って登場してくる、TCP/IP ネットワーク系のツール（ppp, tcpdumpなど）。
• 1989年頃から登場し始めた giflib, libjpegなどの画像処理系ライブラリ。
• 1995年頃から登場した zlib, bzip2 などのデータ圧縮・展開ライブラリ群。libpng のように zlib に依存した画像処理なんかも登場します。
• 1998年頃から揃ってくる動画、音声、XML などの各種データフォーマットを扱うライブラリ。
• 2003年頃から登場してきた、LLVM や Apache Ant、JUnit などの開発環境、テスト自動化系のツール群。

スマートフォンが音声や映像、通信を扱うことを考えると入っていておかしくないものばかりですが、有名ツール、プロジェクトがけっこう入っています。約半分は Android が発表される以前のもの（Copyright を見ると 2008年以前）となっていて、実績を積んできたソフトウェアたちが今も活躍しています。COBOL のプログラムが今も企業のビジネスを支えていたり、昔のゲームソフトが今も遊ばれているのと同じように、「必要なソフトウェア」は、しっかり長生きしています。

プロジェクトの由来は手作業で調べているので、勘違い等もあるかもしれませんが、これらのソフトウェアの Copyright には Microsoft や Intel、Apple、複数の大学の名前も入っていて、コミュニティ全体で協力して信頼できる基本部品を整えるという最近の時流がよく分かる事例になっていると思います。気になる方は、ソースコードをダウンロードして Copyright という文字列を検索してみてください。

コードレビューでは1000回以上繰り返されている修正もある

コードレビューでは同じような修正を何度も繰り返しているしているように見えるという知見は、 if 文に関する下記の研究で判明していました。

ishiotks.hatenablog.com

この研究の続きとして、コードレビューで行われた任意の修正のうち、何度も繰り返されているものだけを取り出すパターンマイニング手法を定義し、さらに調査してみました。2019年2月に開催されたソフトウェアクローンに関するワークショップ（IWSC 2019）にて、以下のタイトルで発表しています。

Mining Source Code Improvement Patterns from Similar Code Review Works

この研究では、過去の研究と同様に、投稿されたパッチの最初の版と、レビューが完了してソースコードに取り込まれた最後の版の差分を分析しています。レビューによる差分として、たとえば以下のような情報が取得できます。

- i = dic["key"]
+ i = dic.get("key")

この研究では、この差分内容自体から、「よくある修正」のマイニングを試みています。具体的な方法としては、以下に示すように、コードレビュー差分情報を含めたトークンの系列を生成しています。

i = dic

- [

+ .get(

"key"

- ]

+ )

行の先頭に "-" が付いたものがレビューで削除されたトークン、"+" の付いたものが追加されたトークンです。i=dic、"key" という行については変更されていないことを示しています。

パッチをそれぞれこのような系列に変換した後、数値は NUMBER に置き換えるなど少し正規化操作もかけてから、系列データマイニング（Sequential Pattern Mining）のアルゴリズムを実行します。これによって、よく行われている修正と、その前後にいつも出現しているトークンを抽出しました。マイニングのアルゴリズムには、動作原理が分かりやすく、そこそこの性能を持つ PrefixSpan を使いました。

OpenStack プロジェクト群の 616,723 個の変更に対してマイニングをかけた結果から得られたパターンには色々含まれていました（詳しくは論文の Table 1参照）。たとえば、以下のパターンは、1,149個の変更に出現していました。

self.assertEqual

+ NUMBER ,

- , NUMBER

 これは、self.assertEqual(_, NUMBER) が self.assertEqual(NUMBER, _) に置き換わっているらしいことを示したパターンになっています。assertEqual の第1引数に期待された値、第2引数に実際のプログラムから計算された値を入れるので、それを守っていなかったテストコードを修正してきたことがうかがえます。このパターンを含めて、出現頻度の高いパターン群 5個について StackOverflow に対応する質問が見つかりましたので、「一度は解説を読んだことがないと分からない」というタイプの知識が、開発者にうまく広まっていない可能性があると考えています。

修正パターンのうち、修正回数が 5,000回を超えていたものは2つでした。その１つは単体テストの TestCase クラスに関する関数呼び出しを置き換えるものです。

self.

+ stub_out

- stubs . Set

)

この置き換えの理由については、以下のように API ドキュメントに記載されています（レビューが行われた時期とドキュメントに書かれた時期のどちらが早いのかまでは、残念ながら分かっていません）。

stub_out(old, new)

  This should be used instead of self.stubs.Set (which is based on mox) going forward.

  The nova.test Module — nova 13.1.2 documentation

こちらはプロジェクト固有の事情によるところがありそうで、先ほどのテストの書き方よりも、さらにマイナーな知識になっていることが、この修正回数に反映されているように思います。

開発者が新しいルール（たとえば使うべきでない機能）を定義し周知できればそれで良かった可能性もありますが、なるべく手間を発生させないために、このような新しいルールの出現を自動で検知し、開発者にうまく伝える仕組みというのも、研究室で今後の課題として考えていく予定です。

（ 2019年3月5日追記）本論文は、IWSC2019 において参加者の投票によって People's Choice Award に選ばれました。受賞に関するページにて、ワークショップで使用した発表スライドを公開しています。

OSS プロジェクトに寄付をした人に「親しみを感じる」ことの影響

オープンソースソフトウェアプロジェクトの運営において、寄付は重要な要素であると言われています。Eclipse では、寄付した人に対する特典として、バグ報告等を行うための Issue Tracking System において、寄付をした人の名前の横に "Friends of Eclipse" というバッジ（以下、寄付バッジ）が表示されるようになっています。

この寄付バッジ自体にはそれ以上の意味は用意されていないのですが、開発者がそれを見てそのバグ報告を優先して取り扱うなどの行為が起きるのではないか？という仮説を立てて調査を行いました。IEEE Software という雑誌に掲載が決まっており、既に公式サイトには著者最終版が上がっています。

Are Donation Badges Appealing? A Case Study of Developer Responses to Eclipse Bug Reports - IEEE Journals & Magazine

この調査では、統計的因果推論という手法を使っています。バグ報告者のうち、寄付バッジを持っている人たちのグループと、同じぐらい働いている人が寄付バッジを持っていない人たちを抽出し、彼らのバグレポートに対して最初に返事が返ってくるまでの時間を分析しました。以下は、寄付バッジという仕組み自体が導入される前後での２つのグループに対する返答時間を図示したものです。

上記論文の Fig.1 を引用。寄付バッジ導入前後での返答時間の変化。

横軸が時間で、 Before が寄付バッジ導入前、After が寄付バッジ導入後です。縦軸がバグレポートへの返答の時間で、Response trend in donors が寄付した人たちのバグレポートに関するもの、Response trend in control group が対照群です。

この図を見ると、寄付バッジ導入後、両方の群で返答時間は早くなっています。２つの群で、だいたい同じぐらい返答時間が早くなりそうなところ、寄付バッジを持っている人たちのバグレポートに対する返答のほうはさらに早くなっているので、その差が寄付バッジの効果だろうと推測されます。実際の差は２時間ぐらいなので、非常に大きいというわけではないのですが、誰かに強制されたわけでもないのに効果が出てしまうという点が面白いところです。

この結果に関連して、Eclipse の開発者の人たちは寄付バッジをどう思っているか、 Eclipse Foundation に協力していただき、 Eclipse コミュニティの皆さんにアンケートを取ることができました。この結果は、ソフトウェアエンジニアリングシンポジウム 2018 の一般論文として報告しています（著者版はこちら）。大事なところだけ要約すると、以下の通りです。

• バグレポートを読む、バグレポートにコメントする、バグを修正するどの段階でも、自分がよく知っているコンポーネントに対するものや、深刻度が高いものを優先する。
• 誰がそのバグレポートを書いたのか、寄付バッジを持っているかは、重要ではない。
• 寄付バッジに対しては friendly と感じる人が多く、knowledgeable とか respected と感じる人は少ない。

開発者が「誰が言っているか」ではなく「何を言っているか」を見ていることは、開発者たちの素晴らしい姿勢だと思います。それにも関わらず寄付バッジによって実際には返答時間が早くなっているので、２時間の差は、開発者が寄付バッジを見て「親しみを感じる」ことによって無自覚に行動が早くなった影響なのかもしれません。

開発者間のコミュニケーションを円滑に進めるのに、寄付バッジという簡単な表示だけでも効果があったという点は、開発環境を取り巻く制度設計も重要であることを示唆していると思います。研究としては、今回のように「この制度が効果があった」ことを調べるのは可能ですが、「効果がありそうな制度」を考えるのは難しいところですので、今後も多くのプロジェクトでの成功例・失敗例を収集、分析していく必要がありそうです。

バグのあるプログラムからバグのないプログラムへの機械翻訳

機械翻訳技術は、たとえば英語の文を日本語の文へと自動的に翻訳するというのが一般的な使い方だと思います。ソフトウェア工学分野では、これを「バグのあるプログラム文からバグのないプログラム文への翻訳」とすることで、バグ修正に適用する方法を実験しています。

arxiv.org

Neural Machine Translation 技術は、対応関係のある文の組をたくさん用意してニューラルネットワークを構築し、そこに新しい文を入れると翻訳文が出てくるという手法です。そこに1文だけ命令が修正されたようなバグ修正を学習データとして投入します。1文だけの修正というのはバグ修正の中ではかなりの割合を占めていることが知られていて、たとえば以下は Apache Camel プロジェクトでの修正の事例です。

  uptime /= 24;
  long days = (long) uptime;
- long hours = (long) ((uptime - days)*60);
+ long hours = (long) ((uptime - days)*24);
  String s = fmtI.format(days) + (days > 1 ? " days" : " day");

このような事例を大量に集めて、修正パッチで削除された文（マイナス記号の付いている行）から修正パッチで追加された文（プラス記号の付いている行）への「翻訳」を学習するわけです。実験では5プロジェクトの最大10年ほどのバグ修正履歴から、 35,137件の学習データを収集して使用しています。

ソフトウェア工学における自動デバッグの研究は、「修正結果のコードのほとんどは実は対象プログラムのソースコードのどこかに既に存在していることが多い」という観測結果に基づいていて、コードを対象プログラム内部のどこかからコピーしてきて移植する形成外科（Plastic Surgery）アプローチから始まっていました。このアプローチと比較すると、「行の中をちょっとだけ直す」バグ修正に強い傾向がありそうだ、ということが分かりました。たとえば以下のような修正です。

- Set<String> knownRoles = new HashSet();
+ Set<String> knownRoles = new HashSet<>();

これは、まったく同一の文はプログラム内部に存在しないが、同じような書き換えが何度もあった事例です。このほかにも "this." の追加や式中に登場する配列の添え字の修正などをうまく実現していました。

2018年には同系統の関連論文も登場しており、アプローチ自体が発展途上の段階にあります。学習データとして大量の修正の履歴を蓄積していく必要があるため、今後どこまで発展するかは分かりませんが、よくある書き間違いに対しては、エディタがバグ修正を提案してくるようになるだろうと思います。

オープンソースソフトウェアプロジェクトの人口ピラミッド

オープンソースソフトウェア開発において、開発者の人数は非常に重要です。最近は企業に雇われてフルタイムで働く開発者も多くなっていますが、一時的にプロジェクトに関わってくれる人たち、単発で貢献してくれる人たちの貢献度も無視できません。

あるプロジェクトに参加している人たちの人数が今後も安定しているのか、増加あるいは減少するのか、ある程度でも予測できれば、プロジェクトの中の人にとってはプロジェクトの運営方針に、ユーザにとっては安心して利用し続けられるかどうか、考えやすくなる可能性があります。

そんな用途に、人口統計の可視化に使われる「人口ピラミッド」を使うことを試してみた研究がこちらです。

doi.org

通常の人口ピラミッドは男女別、年齢別での人数を可視化しますが、オープンソースソフトウェアプロジェクトでは、「最初にプロジェクトに関わったとき」出生という扱いにします。プロジェクトへの関わり方は色々ありますが、GitHub 上のアクティビティとして、コミットや Issue へのコメントなどを調べています。そして、最後の貢献から３か月以上経過したら、そのプロジェクトから去ったとみなして人口ピラミッドから取り除くことにします。このルールで実際に作ってみた例を以下に示します。

JQuery プロジェクト（2015年）の人口ピラミッド、上記論文から引用

左右は男女の別のかわりに、左側がコーディング以外で関わっている人、右側がコーディングで関わっている人という形で２つのグループに分けています。右側の白い部分は「以前はコーディング以外で貢献していた」人たち、黒は元々開発者として加わった人たちになります。

この図を見ると、少数の人たちが長期間に渡ってプロジェクトを支える一方で、多数の新しい人たちもプロジェクトに参加していることが分かります。プロジェクトによっては、１人の開発者だけがずっと頑張っていて、その人がやめた瞬間にプロジェクトが終わるというものもありますが、そういう状況を可視化できたら、誰かが（もし重要なプロジェクトであれば）終了前に引き継ぐことができるかもしれません。プロジェクトごとにそれぞれ事情もあるので、この可視化手法が常に有用であるとは主張しにくいのですが、プロジェクトがどんな状態かを考える方法の１つとして提案しています。

なお、この人口ピラミッドを使うと各年齢での人口の生存率が計算できるので、コーホート要因法という人口推計の手法が適用できます。論文では、やや単純ではありますが、「３か月後どうなっているか」をこの手法で予測してみて、「今と同じ人数がそのままいる」という単純な予測よりは、少し正確に予測ができることを確認しています。以下は、人口ピラミッドに、推計した値の線を書き入れたものです。

プロジェクト参加人数予測（線）と人口ピラミッドを重ねたもの、上記論文から引用

この手法ですぐに具体的な問題が何か解決できるようになるというわけではありませんが、ソフトウェア開発の社会的な側面を科学的に分析するという方法もあるのだということは示していると思います。

パッチ投稿経験が増えてもパッチに含まれる軽微な問題の個数は減らない

パッチを投稿してコードレビューを経験するほど、自分でパッチの問題に気付くことができるようになり、投稿パッチに含まれる間違いが減っていくのではないか。そんな仮説に基づいて、開発者のパッチ投稿回数（＝経験値）と、パッチに含まれる軽微な問題の件数の関係を調べてみました。

Yuki Ueda, Akinori Ihara, Takashi Ishio and Kenichi Matsumoto: Impact of Coding Style Checker on Code Review -A case study on the OpenStack projects-

この論文では「手作業で直している軽微な問題（論文中では Manually Detected Issues）」を、Pylint のような静的解析ツールでは検出できず、レビューで直されているような修正として定義しました。いわゆるバグ修正のような大事なものは取り除きたかったので、ここでは１つのコード断片に収まっていて、しかも特定の文字種（アルファベットだけ、空白だけ、文字列だけ、など）の修正だけで直るようなもの、という便宜的な方法で抽出しています。この抽出方法は、過去の研究で目視での検査をしたときに、レイアウトの変更や変数名の変更など動作には変化がなさそうな変更をある程度の正確さ（文字種にもよりますが90％ぐらい）で取れることが分かっていたからです。

データセットには、ほかの研究と同じく、OpenStack のものを使っています。20回以上パッチを投稿したことのある人（1599人）に絞って分析しました。この人たちだけで80％ぐらいのパッチを投稿しています．

結果はというと、軽微な問題の累計数はパッチ投稿回数とともにだんだん増えていく、つまり経験に従って減っていく傾向などは出ませんでした。開発者はある一定の割合で間違いをするので、レビューを担当する人は、相手が誰であっても細かいミスがないかどうか、しっかりレビューすることが重要になります。

同時に調べた Pylint で自動的に検出できる問題 （論文中では Automatically Detected Issues）は高々1～3回でそれ以上は発生しなくなるので、こちらはツールをきちんと利用して、開発者側でうまく抑制している可能性があります。小さい誤りの混入を抑制するには、うまくツール化することが重要といえそうです。

なお、この結論は、「レビュアーはほとんど小さな誤りを見逃してない」 前提で書いてるもので、レビュアーが小さな誤りをほとんど気にせず素通しして、別途パッチを作って直しているのだと成り立たなくなります。このあたりは、レビューのデータにのみ頼っている調査の限界になります。