先日学生さんの新卒面接をさせて頂く機会がありました。
いろいろ新発見
があり勉強になったので、今回はそのひとつを紹介したいと思います。
「プログラムをする上で気をつけている事は何ですか？」
という質問に
「自分以外の人が読んだ時に分かりやすいソースを書くように気をつけています」
という回答を頂くことが多かったのですが、分かりやすいソースの判断基準は
主観的で評価が難しいなぁと感じました。
（※分かりやすくなるように心がけるのは大事で必要な事だと思います。）
確かにコメントをしっかりつけたり、コーディング規約を設けて、それに沿って
コードを記述することで分かりやすくなると思います。
ですが、さらにその精度を上げられないものかと思って調べてみると、
何と私が生まれる以前にプログラムの複雑度を測る方法が開発されていました。
ソフトウェアを分析/計測する方法をソフトウェア測定法（ソフトウェアメトリック）と
いうのだそうですが、その中でも、プログラムの複雑度を測るのに使われる
循環的複雑度（Cyclomatic complexity）というものがあるそうです。
「複雑なプログラム＝潜在的にバグが入りやすいプログラム」という観点から
プログラムの制御構造の複雑さを測定し、バグの発生率を下げることを目的としたもので
一般的には、以下のような判断値となるようです（※計測ツールにより多少異なるようです）。
10以下 ― 保守し易く良好
11〜20 ― 場合によりロジックを再検討する必要がある
21〜40 ― 理解に時間がかかる
41〜50 ― 開発者のみ改修可能
51以上 ― 理解不可能
簡単な概念は、線形的に独立したプログラムのソースコードの経路の数を数えて
数が多い程、複雑度が高くなるというもので、
ソースコードの経路数が多い＝プログラムの実行経路の数が多い＝テストケースの量が増える
ということになるようです。
また複雑度が高いと、ソースコードの意味を理解するために多くの経路を追わなければならず
読解が困難になるともいえますね。
試しに私の就職活動で作成したプログラムをフリーの計測ツールにかけてみると…
おおむね10ポイントを下回っていてホッとしたのもつかの間
いくつか 15〜27 ポイントのソースコードが…
循環的複雑度だけを基準に優れたソースコードか否か、という判断はできませんが
自分の書いたプログラムが複雑になっていないか、客観的な指標とするには
良いかもしれません。
気が向いた時にだけ測るのではなく、以前このブログで紹介した Hudson
（現在はJenkinsと名前が変わっているようです）と組み合わせて、日々計測を
行うと効果的かもしれませんね。
ではまた
