Pythonメトリックコードpymetricsは、コードファイルの複雑さを分析するために使用できます。それらは2つの異なるメトリックを作成します。
McCabe Complexity Metric関数とクラスの場合COCOMO 2's SLOC Metricファイル全体のAこれらのメトリックの数値が何を意味するのかを知りたいのですが、実際にはそれらの定義ではありません。「1」の値はどういう意味ですか？「5」の数？「10」の数？高い方が良いですか、それとも低いですか？どの数値が良いコードを指し、何が本当に悪いコードを指しますか？インターネットを検索するといくつかのヒントが得られますが、分類がメトリック（1）とメトリック（2）のどちらを指しているのかわかりません。私はこれらの数字の両方に意味を持たせたいと思います。
あなたの質問には、良いコードには特定のメトリックに対して特定の値があるという問題のある仮定があると思います。単一のメトリックでコードの品質を実際に測定することはできません。それは物事の組み合わせであり、コンテキストにも大きく依存します。本当に本当に超効率的なコードは、通常、理解するのがやや難しいですが、それはそれを悪いコードにしますか？
IBMは、70年代のプログラマーの品質を、彼らが作成するコード行（SLOC）で測定することを決定しました。言うまでもなく、その結果、非常に長くてばかげたコードが作成されました。
コードの品質を理解したい場合、必要なのは他の開発者がそれを確認することです。できれば、あなたよりもはるかに経験豊富な開発者。フレンドリーなコードレビューは学習に最適です。また、他の方法ではなく、自分が行った方法で何かを行った理由について考える必要があります。幸いなことに、stackexchangeはまさにそれを提供します。
ウィキペディアから
循環的複雑度（または条件付き複雑度）は、ソフトウェアメトリクス（測定）です。1976年にThomasJ.McCabe、Sr.によって開発され、プログラムの複雑さを示すために使用されます。プログラムのソースコードを介して線形独立パスの数を直接測定します。概念は、方法ではありませんが、フレッシュ・キンケード可読性テストによって測定された一般的なテキストの複雑さの概念にいくぶん似ています。... ソースコードのセクションの循環的複雑度は、ソースコードを通る線形独立パスの数のカウントです。たとえば、ソースコードにIFステートメントやFORループなどの決定ポイントが含まれていない場合、複雑さは1になります。、コードを通るパスは1つしかないためです。コードに単一の条件を含む単一のIFステートメントがある場合、コードには2つのパスがあります。1つはIFステートメントがTRUEと評価されるパスで、もう1つはIFステートメントがFALSEと評価されるパスです。
1それがより良いとは言えません2、それは文脈（あなたが書いている言語、コードを書いている人など）に依存します。循環的複雑度の値は、コードの制御フローを理解するのがいかに簡単であるかについてのヒントを与えるものと考える必要があります。ネストされたifステートメントが多いと、CCが高くなります。したがって、理想的には、CCが1（おそらく関数ごと）になります。つまり、1つの関数が1つの方法で1つのことを実行し、他には何も実行しませんが、それが常に可能であるとは限りません。コンテキスト内のメトリックに対して取得した値を評価する必要があります。
同じ言語で書かれた他の図書館では、どのような価値観を見る傾向がありますか？でも、その数字はお伝えできません（ごめんなさい）。CC値15はおそらく少し上であり、コードをリファクタリングする必要があると言えます。これは、スクリプト/関数を実行する15の異なる方法です。その1つの関数のテストで考慮する必要がある15の異なる条件、およびそれらの15のことを機能させない可能性のあるすべてのことを忘れないでください。それらの別の単体テストと値の組み合わせが必要になります（ポイントを取得します）。
ソースコード行（SLOC）は、プログラムのソースコードのテキストの行数をカウントすることにより、コンピュータープログラムのサイズを測定するために使用されるソフトウェアメトリックです。SLOCは通常、プログラムの開発に必要な作業量を予測するため、およびソフトウェアが作成された後のプログラミングの生産性または保守性を見積もるために使用されます。
建設的コストモデル（COCOMO）は、BarryW.Boehmによって開発されたアルゴリズムによるソフトウェアコスト見積もりモデルです。モデルは、過去のプロジェクトデータと現在のプロジェクト特性から導出されたパラメーターを持つ基本的な回帰式を使用します。
一方、COCOMOは実際にはコードの品質を測定していません。これは、ソフトウェアプロジェクト（COCOMO II）の一種のコストモデルであり、より最近の（90年代以降の）ソフトウェアプロジェクトの更新です。
Softwaresystems.comはこう言っています
COCOMO IIは、実際には3つの異なるモデルです。
•アプリケーション構成モデル-最新のGUIビルダーツールで構築されたプロジェクトに適しています。新しいオブジェクトポイントに基づきます。
•初期設計モデル-このモデルを使用して、プロジェクトのアーキテクチャ全体を決定する前に、プロジェクトのコストと期間の概算を取得できます。これは、新しいコストドライバーの小さなセットと新しい見積もり式を使用します。未調整のファンクションポイントまたはKSLOCに基づきます。
•ポストアーキテクチャモデル-これは最も詳細なCOCOMOIIモデルです。プロジェクトの全体的なアーキテクチャを開発した後で使用します。これには、新しいコストドライバー、新しい行カウントルール、および新しい方程式があります。
ファンクションポイントは機能の単位であり、KSLOCは数千のコード行です。したがって、COCOMOモデルは、ソフトウェアプロジェクトのコスト、時間、必要なリソースなどを見積もるためのものであり、コードの品質を評価するためのものではありません。