私の意見では、これらの値に数値制限を課すことは（数字で暗示しているように）、あまり良い考えではありません。重要な switch ステートメントがある場合、メソッドの行数が非常に多くなる可能性がありますが、それでもメソッドは単純で適切です。フィールドが単純な場合、クラス内のフィールドの数は適切に非常に大きくなる可能性があります。また、5 レベルの継承は多すぎる場合もあります。
クラスの結束 (多いほど良い) と結合 (少ないほど良い) を分析する方が良いと思いますが、それでもそのようなメトリックの有用性については疑問です。通常、経験はより良い指針となります (確かに、それは高価です)。
リストに表示されなかったメトリックは、McCabe の Cyclomatic Complexity です。特定の関数の複雑さを測定し、バグと相関関係があります。たとえば、関数の複雑性スコアが高い場合は、1)バグのある関数である可能性が高く、2)適切に修正するのが難しい可能性が高い(例: 修正によって独自のバグが発生する) ことを示します。
最終的に、メトリクスは、管理図のように大まかなレベルで使用するのが最適です。管理限界の上下のポイントを探して、可能性が高い特殊なケースを特定してから、詳細を調べます。たとえば、サイクロマティックな複雑度が高い関数を見て、多くのケースがあるディスパッチャ メソッドであるため、それが適切であることがわかる場合があります。
メトリックによる管理は、人やコードでは機能しません。メトリックまたは絶対値が常に機能するわけではありません。メトリックに魅了されて、コードの品質を真に評価することに気を取られないようにしてください。メトリックは、コードに関する重要なことを示しているように見える場合がありますが、メトリックで実行できる最善の方法は、調査する領域を示唆することです。
それは、メトリックが役に立たないということではありません。メトリックは、予期しない方法で変更されている可能性のある領域を探すために、変更されているときに最も役立ちます。たとえば、継承の3つのレベルから15に、またはメソッドごとに4つのparmsから12に突然移行した場合は、掘り下げて理由を理解してください。
例：データベーステーブルを更新するためのストアドプロシージャには、テーブルに列があるのと同じ数のパラメータが含まれる場合があります。このプロシージャへのオブジェクトインターフェイスは同じである場合もあれば、データエンティティを表すオブジェクトがある場合は1つである場合もあります。ただし、データエンティティのコンストラクターには、これらのパラメーターがすべて含まれている場合があります。では、この指標から何がわかりますか？あまりない！そして、コードベースにこのような状況が十分にある場合、ターゲット平均は水から吹き飛ばされます。
したがって、何かの絶対的な指標としてメトリックに依存しないでください。コードを読んだりレビューしたりすることに代わるものはありません。
個人的には、これらのタイプの要件を順守するのは非常に難しいと思います (つまり、20 行を超えるメソッドが本当に必要な場合もあります) 。体操(興味がある場合は、 Thoughtworks アンソロジーの一部)。
彼はまた、「else」キーワードも getter や setter も使用しないことを提唱していますが、それは少しやり過ぎだと思います。
他の人が言っているように、厳格な基準を守ることは難しいでしょう。これらのメトリックの最も価値のある使用法の1つは、アプリケーションが進化するにつれてそれらがどのように変化するかを監視することだと思います。これは、機能が追加されたときに必要なリファクタリングを実行するためにあなたが行っている仕事がどれほど優れているかを知るのに役立ち、大きな混乱を防ぐのに役立ちます:)
OO Metrics は、私にとってちょっとしたお気に入りのプロジェクトです (それは私の修士論文の主題でした)。はい、私はこれらを使用しており、独自のツールを使用しています。
何年もの間、Mark Lorenz による本「Object Oriented Software Metrics」は、OO メトリクスの最良のリソースでした。しかし最近、私はより多くのリソースを見てきました。
残念ながら、他の締め切りがあるため、ツールに取り組む時間がありません。しかし最終的には、新しいメトリック (および新しい言語構造) を追加する予定です。
更新 現在、このツールを使用して、ソースで発生する可能性のある問題を検出しています。いくつかのメトリックを追加しました (すべてが純粋な OO ではありません):
まだまだあります。コードの問題点のイメージをよく示すものを保持します。したがって、これらが修正された場合は、直接フィードバックがあります。
厳密な数値は、すべてのソリューションで機能するわけではありません。一部のソリューションは、他のソリューションよりも複雑です。これらをガイドラインとして開始し、プロジェクトがどこに行き着くかを確認します。
しかし、これらの数値に関しては、これらの数値はかなり高いようです。私は通常、私が通常持っている特定のコーディング スタイルを見つけます。
これらの一般論を決して調べないというわけではありませんが、たいていの場合、物事を分解できるので、そうするときは通常、コードについてもっと考えます。