ソースコードの読みやすさの一側面: 判読性(Legibility)

ソースコードの読みやすさの視点を調べた研究をいくつか紹介します。
A Systematic Literature Review on the Impact of Formatting Elements on Program Understandabilityというサーベイ論文での分類を参考にしています。古い研究も対象になっていて、印刷したときの横幅に合わせるといった研究も対象になっています。

出典は以下のとおりです。

タイトルのとおり、ソースコードの読みやすさに影響する書式に関する研究を集めています。空白(Spacing), コードブロックの区切り(Block delimiters)、長い/複雑なステートメント(Long or complex code line)、単語の区切り(Word boundary styles)、整形(Formatting style)に分類しています。この順に紹介します。

多くの研究で読み終わるまでの時間、ソースコードの内容の理解を問うクイズの正解数を指標としていて、実際にエンジニアや情報系の学生にソースコードを読んでもらって、短時間で正しく読めているかを試しています。

空白(Spacing)
インデントのスペース(等幅フォントで2, 4, 8)に関していくつか実験があります。インデントがない場合と比べるとインデントがあったほうがよいというのは多くの実験で一貫しています。スペースに関して2個分が他の個数と比べて、統計的に有意に読解時間が短くなり正しい理解につながっているという結果が1件あります。インデントは読みやすさに影響を与えるけれど、スペースの数で差がつくことはあまりない、となりそうです。

コードブロックの区切り(Block delimiters)
コードブロックを{}で囲むタイプのプログラミング言語でこれらの括弧を独立した1行として記述したほうがよいか、他のステートメントと同じ行にしたらよいかを比較した実験があります。独立した1行を使う場合とそうでない場合の例を下に示しています。複数の実験がありますが、読む時間と正しく読めるかという点で一貫した結果とはなっていません。開発者の好みの差を報告した研究はあり、その調査では独立した行に括弧を書くスタイルが好きな開発者が多いと報告しています。

独立した行を使わない例
if (x > 0) {
  y = 0;}

独立した行を使う例
if (x > 0)
{
  y = 0;
}

また、C言語のようなコードブロックが1行のステートメントのみの場合には、括弧を省略できるときや紛らわしい括弧やインデントがある場合には、読む時間や理解しづらさに統計的に有意な差があることが報告されています。以下のようなインデントと括弧の組み合わせで、y++はxの値にかかわらず実行されますが、y = 0はxがゼロより大きいときしか実行されません。一見するとy++もxがゼロより大きいときしか実行されなさそうなのですが、こうした紛らわしいインデントや括弧の省略があると時間や正しく読めるかという点で統計的に有意な差があったことが報告されています。

if (x > 0)
  y = 0;
  y++;

長い/複雑なステートメント(Long or complex code line)
長いステートメントは80文字以上の長いステートメントを1行におさめることを指しています。1行に複数のステートメントを含めることを複雑なステートメントとしています。これらは両方とも避けたほうがよいと考えるエンジニア、学生が多いという意見が報告されています。

単語の区切り(Word boundary styles)
複数の単語からなる識別子の名前をどうつなぐかを指します。つないだ直後の単語の1文字目を大文字にするキャメルケースとアンダーバーでつなぐものが比較されています。たとえば、minimuとvalueをつないで識別子名にしたいとき、minimum_value とするかminimumValueを長いステートメントは80文字以上の長いステートメントを1行におさめることを指しています。こちらは、ソースコードの理解の時間や正しさは比較していませんが、該当する識別子を開発者や学生に探してもらって、見落としがあるかどうかや見つかるまでの時間を比較しています。一貫した実験結果ではないのですが、アンダーバーのほうが見落としが統計的に有意に少ないことを報告した論文があります。

整形(Formatting style)
古い話なのですが、本のような読みやすさに配慮したコードの整形とそうでないものが比較され、読みやすくしたほうがよいという意見やそのままでよいという意見があった時期があります。たとえば、Book format styleやPretty-printed styleやKerningham & Ritchie styleです。具体的にはプログラミング言語の文法上は必要がないけれど、適宜改行やスペースを追加したり、1行が長くなりすぎず印刷しても読めるようにするといった工夫です。ほとんどの研究で、整形したほうが読み間違いが減り、読んだエンジニアや学生からも好ましいという点で統計的に有意な差がある結果を得ています。ただし、整形しても読む時間は必ずしも短くはならないという結果がいくつかあります。

今回紹介したサーベイ論文は既存の論文をまとめて現状を整理するサーベイ論文です。サーベイ論文の読み方はこちらで紹介していますので、原典を確かめたいという方はこちらをごらんください。