保守性指数(MI)の推奨値は次のとおりです。
- 85以上:良好な保守性
- 65-85:中程度の保守性
- 65以下:本当に悪いコード(大きな、コメントされていない、構造化されていない)で維持するのが難しいMI値は負になることさえあります
これらの値はテクノロジーに依存していますか?たとえば、70の値はメインフレームには適していますが、Javaでは維持するのが難しいですか?
テクノロジーに関係なく同じ基準を使用できますか?
保守性指数(MI)の推奨値は次のとおりです。
これらの値はテクノロジーに依存していますか?たとえば、70の値はメインフレームには適していますが、Javaでは維持するのが難しいですか?
テクノロジーに関係なく同じ基準を使用できますか?
保守性指標値の意味について説明します。
あっという間にこれは
MI = 171 - 5.2*ln(Halstead Volume) - 0.23*(Cyclomatic Complexity) - 16.2*ln(Lines of Code)
0 から 100 の間でスケーリングされます。
簡単にわかるように、このメトリックはあらゆる手続き型言語に使用できます。
保守性指数は経験式です。それは、観察と適応に基づいてモデルを構築したことです。詳細を検索すると、特定の言語に対して方程式を調整する必要があることがわかります。SEI のバージョンは、Pascal と C 用に調整されており、Hewlett-Packard が管理する平均 50KLOC のプログラムを多数使用しています。
Visual Studio バージョンのキャリブレーションは SEI バージョンと同じですが、ドメインを 0 から 100 に制限するためにパドロン化されました。
開発者がコードを保守するのがどれほど簡単かを数値で表すことはできないと思います。
経験、文化、読解力などに応じて、さまざまな人が同じコードを見て、独自の方法で解釈します。
そうは言っても、メトリクスはテクノロジーによって確実に異なります。まったく異なる構文、規則、用語などを見ています。低レベルのメインフレーム コードと、Java や C# などの高レベル言語との難しさの違いをどのように定量化できますか?
メトリクスは 1 つのことだけに有効だと思います: ガイドラインです。コードの品質に関しては、コード ベースを説明する以外の目的で使用するべきではないと思います。それらは、難易度や "grok-ability" の決定要因として使用されるべきではありません。
「保守性指標」の計算方法によって異なります。言語が非常に異なるという理由だけで、これは言語間で機能するものとは思えません。
「関数あたりの行数」を単純に比較するのは合理的に思えるかもしれませんが、ポインターでいっぱいの C コード、テンプレートでいっぱいの C++ コード、C# と LINQ クエリ、または Java とを比較してみるとどうなるでしょうか。ジェネリック?
これらはすべて保守性に影響しますが、意味のあるクロス言語の方法で測定することはできません。