循環的複雑度(ブログ・英語)とは、ソフトウェア測定法であり、指定されたコードの複雑度を測るのに使われる。コードから実行経路数を数える。たとえば、分岐を含まない コードのブロックの複雑度が1だとする。if文を追加すると2つの経路が生じ、一方はif文での条件が真となる場合の経路で、もう一方はそれが偽となる場合の経路である。
ソフトウェアデベロッパは可読性を高めるよう、複雑度の小さいコードをビルドし、維持するよう取り組んでいる。しかしながら、近ごろメトリクスダッシュボードプロバイダであるEnerjy(source)が研究結果を発表したことで、その理論に疑問が投げかけられている。Enerjyは、数万にもおよぶソースファイルを 分析(ブログ・英語)し、循環的複雑度(CC)に対して問題の相互関係を示した。
研究結果では、CCが11のファイルがエラーが潜在している可能性が最も低いことを示している(28%)。CCが38のファイルは50%の確率でエラーが潜在している。CCが74以上のファイルでエラーが潜在しているは、98%以上であると決定付けられた。
SDTimesのAndrew Binstock氏(source)が興味深い見解を示した。
Enerjyが発見したのは、CCNが1から25のルーチンは、CCNが大きくなるとエラーになる可能性が高くなるという予想される結果にはならないこと である。もっと正確に言うならば、CCNが1から11までについては、CCNが大きくなればなるほど、バグの可能性は低くなるということである。CCNが 25に到達してはじめて、CCNが1のルーチンのエラーの可能性までエラーの可能性が上昇した。
Enerjyによる研究結果によって、CCの数え方に関して多少の混乱が生じた。Keith Braithwaite氏(source)は、Enerjyの研究ではメソッドレベルではなく、ファイルレベルでCCを数えている、と指摘した。Christopher Beck氏(サイト・英語)は、The Quality of TDD(source)に同意を示したコメントを以下のように残している。
それは、CCではない (上にCCと呼ぶべきではない)。どちらかといえば、それはクラスのCCを数えるWWC(Weighted Methods per Class)と呼ばれる別のメトリクスに近い。
CCの計算に対するEnerjyのアプローチはともかく、明確になったことがある。それは、CCが74以上になると、かなりの確率でバグが出るということである。
原文はこちらです：http://www.infoq.com/news/2008/03/cyclomaticcomplexity