コード比率の循環的複雑度/行を計算することは意味がありますか？

一般に、保守性インデックスは多くの要因に依存しています。たとえば、Visual Studioでは、循環的複雑度、継承の深さ、クラス結合、コード行に依存しています。これらの4つの値はできるだけ低くする必要があります。

同時に、コードメトリックツールでも、書籍でも、循環的複雑度（CC）とコード行（LC）のみの比較を見たことはありません。

そのような比率を計算することは意味がありますか？コードについてどのような情報が提供されますか？言い換えると、LCを下げるよりもLCを下げる方が良いでしょうか？

私が気づくのは、小規模なプロジェクトの場合、CC / LCの比率が低い（1/2以下）ことです。つまり、LCは高く、CCは低くなります。大規模なプロジェクトでは、CC / LCはほとんどの場合thanより大きくなります。どうして？

http://en.wikipedia.org/wiki/Cyclomatic_complexityから

Les Hattonは最近、McCabe Cyclomatic Complexityにはコード行と同じ予測能力があると主張しました（TAIC-PART 2008の基調講演、英国ウィンザー、2008年9月）。

この比率には、個別に使用する場合とほぼ同じ予測能力があります。

ソースステートメントごとに循環的複雑度の測定基準があります。これは循環的複雑度密度と呼ばれます。このメトリックは、ソフトウェアプロジェクトに必要なメンテナンス時間と労力を推定するために使用できます。

以前の回答で述べたように、受け入れられた回答のこのステートメントは明らかに正しくありません。

この比率には、個別に使用する場合とほぼ同じ予測能力があります。

CC密度は、さまざまな研究者によって理にかなっていることがわかっていますが、開業医の間でかなりの人気を得ているようには見えません。ソフトウェアメトリック領域の2人の著名な学者によると、比率（循環的複雑度密度= CC / KLOC）は、CCまたはKLOC単体よりもはるかに優れたメンテナンス生産性の予測因子であるという証拠があります。

GKギルとCFケメラー、「サイクロマティック複雑度密度とソフトウェアメンテナンス生産性」、IEEE Transactions on Software Engineering、vol。17、いいえ。12、pp。1284-1288、1991年12月。doi：10.1109 / 32.106988

CC密度ベースのメトリックを改善するためにこの作業に基づいて構築された他の多くがあります。2つの例：

1. T.アンダーソン、K。エンホルム、A。トーン。ソフトウェアの複雑さの長さに依存しない測定。M.ロス、カリフォルニア州ブレブビア、C。ステープルズ、J。ステープルトン（編）ソフトウェア品質管理に関する第2回国際会議、第1巻、品質システムの管理、1994年。

2. JP Mittal、Pradeep Bhatia、Harish Mittal。2009.ファジーロジックを使用したソフトウェアメンテナンスの生産性評価。SIGSOFT Softw。工学 ノート34、5（2009年10月）、1-4。DOI = http://dx.doi.org/10.1145/1598732.1598739

申し訳ありませんが、私はこの声明に同意しません：

この比率には、個別に使用する場合とほぼ同じ予測能力があります。

比率は明らかに個々のメトリックと同じではありません。経験的データに基づくと、ハットンは、CCはXLOCに比例し、特定のデータセットでは約0.25の一定の比率（スライド17を参照）であると主張しています。したがって、XLOCが60であるか400であるかに関係なく、CC：XLOC比は約0.25になります（高い数値での統計的偏差を無視）。したがって、比率はまったく予測できません。