計測できそうでできない多くのこと。エンピリカル(実証的)アプローチで。

ソースコードのコメントよりも空白行のほうが理解を助けるという研究結果

»

IEEE Transaction on Software Engineeringの論文Raymond P.L. Buse and Westley R. Weimer: Learning a Metric for Code Readabilityから。120人の被験者が10種類のオープンソースプロジェクトのソースコードの一部(20行等、非常に局所的)をもとに読みやすさに影響を与えることを実験結果から示している。

25種類のメトリクスと読みやすさとの相関を求めている。メトリクスには、コメント行数や予約語の数、空行の数、括弧の数、変数名の長さ、変数の個数などが含まれる。このうち、読みやすさに最も影響を与えやすいメトリクスとして、1位に変数の個数、2位に行数、3位に括弧の数、9位に空行数、15位にコメント行数が示されている。

この論文では、多くの人に短時間で読みやすさが評価できるように、対象ソースコードは小さなものに限定しているようだ。つまり、10種類のオープンソースのソースコードの断片を100箇所取り出し、それを被験者に評価してもらっている。そのせいか、代表的なソースコードメトリクスであるサイクロマチック数(ソースコードの分岐等の閉経路の数)との相関は比較的小さかったそうだ。

この論文で対象としているソースコードのサイズはいずれも小さく、設計要素、2つのクラスやモジュールの間のインタラクション等、勘案が難しいメトリクスもある。論文では、そのことについて詳細には考察されていないが、規模が異なれば結果は異なるだろうから、さらなる調査が必要になるだろう。ただ、これだけの人数でこれだけのソースコードを調査した事例紹介は少ないので、貴重な文献といえるだろう。

読みやすさと関連する話として、プログラミング言語について書かれた興味深い記事(Publickeyの「プログラミング言語の特徴を、実行速度と簡潔さで見る」)もあるので、ここで紹介しておきたい。この記事では、プログラミング言語の簡潔性と実行速度について興味深い結果が示されている。

これらをもとに、ご自身のソースコードを最も読みやすくしている要因は何で、読みにくくしている要因は何か今一度検討されてみてはいかがだろうか?また、ここ(当学のWebページ)で我々の研究グループでも実施しているソースコード読解の題材がある。その意義はここ(Codezineの記事)で紹介している。最終締切りは2009/11/24なので、試してはいかがだろうか?

Comment(2)

コメント

こん××は。妹尾です。

自分のプログラミング経験のスタートは、何の専門教育も受けない中で、上司からソースを与えられ、「これ、動かない奴。研修がてら、時間掛かって良いから直せる?」いうのを直したり、「これ、これから覚えてもらう言語。これ読んで動き勉強して」なんてことからスタートしたので、空白行で、「ああ、ここで意味合いを分けたいのだな」と察知できることが非常に重要だった気がします。(と言ってもほんの少しの言語しかわかりませんが)

今でも、たまにちょぼちょぼ自分の業務用にExcelのVBAマクロを組みますが、自分の頭の整理のためにも空白行は入れますね。そうしないとまず自分自身が書けない(苦笑)

そうですね。なじみが出てくる前には特に空行に頼る部分も多いですね。

コメントはうまく書いてあると効果絶大なのですが、更新されていなかったり、包括的な説明になっていなかったりするところが難しいんですよね。。

コメントを投稿する