問題タブ [code-metrics]

次のコード メトリクスの計算に適したスコア範囲は?

• 保守性指標
• 循環的複雑度
• 継承の深さ
• クラスカップリング

C# コードのSOLID性を測定するために、どのような指標があり、どのツールが存在しますか? または、原則が最も有害に違反している場所を示すツールはありますか?

ソフトウェアエンジニアリングプロセスでのソースコードメトリクスの使用に関する論文を提出する必要があります。ソースコードメトリックの分類を導入することから始めるのが良いと思いました（たとえば、コードの静的分析を行う平面LOCカウントとを使用して）が、さまざまなタイプの本や記事を見つけることができませんメトリックとおそらくいくつかの歴史的背景情報（本と記事は私のインストラクターによってWebサイトよりも好まれています）。

誰もがそのような情報源を知っていますか？

LinesofCode以外のコード長メトリックを調べていました。ソースモニターが報告するものはステートメントです。これは知っておくと貴重なことのように思えましたが、SourceMonitorがいくつかのことを数える方法は直感的ではないようでした。たとえば、forステートメントは、変数定義、条件、およびインクリメントステートメントが含まれていても、1つのステートメントです。また、メソッド呼び出しが引数リスト内で別のメソッドにネストされている場合、すべてが1つのステートメントと見なされます。

ステートメントがカウントされる標準的な方法はありますか？そのようなことを管理するルールはありますか？

私は、大規模なソフトウェア プロジェクトに関するいくつかの単純なメトリックを計算する、私の古いプロジェクトのほこりを払っています。メトリックの 1 つは、ファイル/クラス/メソッドの長さです。現在、私のコードは、クラス/メソッドの境界が非常に粗いアルゴリズムに基づいている場所を「推測」しています (ファイルをトラバースし、「現在の深さ」を維持し、引用符で囲まれていない括弧に遭遇するたびにそれを調整します。クラスまたはメソッドが開始されたレベルに戻ると、 、終了したと見なします）。ただし、この手順には多くの問題があり、深度がいつ変化したかを検出する「単純な」方法が常に有効であるとは限りません。

これで正確な結果が得られるようにするには、関数定義、クラス定義、深さの変化を検出する正規の方法を (各言語で) 使用する必要があります。これは、プロジェクトを適用したいすべての言語に対して、少なくともこれらの要素を含む解析ツリーを生成する単純なパーサーを作成することになります。

明らかに、パーサーはこれらすべての言語に対して以前に作成されているため、その作業を繰り返す必要はないように思われます (パーサーを作成するのは楽しいものですが)。 多数のソース言語用にすぐに使用できるパーサー ライブラリを収集するオープンソース プロジェクトはありますか? それとも、ANTLR を使用してゼロから独自のものを作成する必要がありますか? (注: プロジェクトを別の言語に移植して、優れた既存のリソースを利用できることを嬉しく思います。そのため、そのリソースを知っていれば、それがどの言語で書かれているかは問題ではありません。)

システムまたはアプリケーションのオブジェクト指向性を判断するのに役立つメトリックはありますか？.NET Reflector Add-ins codeplexプロジェクトでかなりきちんとしたメトリックを見てきましたが、まだこのようなものはありません。そのような測定基準が存在しない場合、それは可能であるか、または有用でさえありますか？オブジェクト指向プログラミングには、カプセル化、継承、およびポリモーフィズムの3つの想定される信条があります。これらに対してプログラムをランク付けしたツールは、オブジェクト指向の理想全体が破棄されたC＃（または同様の）コードベースの領域、およびプロジェクトの他の部分と比較してその領域に関連付けられているバグの数を表示できる場合があります。

Visual Studio のコード メトリクス ルールに関して、次の 2 つのコードの違いを誰かが説明してくれるとありがたいです。内にすべてをカプセル化しないと、保守性指数がわずかに増加するのはなぜusing ( )ですか?

サンプル 1 ( MI スコア 71 )

サンプル 2 ( MI スコア 73 )

メトリクスは、より広い文脈と理解の外では無意味であり、プログラマーは裁量を行使する必要があることを理解しています。でスコアを 76 まで上げることができましたが、そうreturn Convert.ToBase64String(sha1.ComputeHash(Encoding.Unicode.GetBytes(plainText)))すべきではありませんでした。私は明らかに数字で遊んでいるだけであり、その時点でそれは本当に読みやすく、保守可能ではありません。この場合の増加の背後にある論理が何であるかについては興味があります。明らかに行数ではありません。

重複の可能性:
単体テストの妥当なコード カバレッジ % とは (およびその理由)?

単体テストのコード カバレッジに関するガイドラインをまとめている最中で、実際に意味のある数値を指定したいと考えています。費用対効果の分析を考慮せずに、インターネット全体で見られる 100% のマントラを繰り返すのは簡単です。

実際の中規模/大規模プロジェクトのコード カバレッジを実際に報告した人からのコメントを求めます。何パーセント見ましたか？多すぎるとはどのくらいですか？開発者が高品質のコードを作成するのに役立つバランス (数値) が本当に必要です。65% のカバレッジは期待するには低すぎますか? 80%って高すぎない？

人々が言うのを聞いたことがあります (特に誰だったかは思い出せませんが)、コードの 1 行あたりのバグの数は、使用されている言語に関係なくほぼ一定です。これを裏付ける研究は何ですか？

編集して追加: 私はアクセスできませんが、どうやらこの論文の著者は、 「コード行ごとのバグ数 (LOC) が、異なるプログラミング言語で書かれたプログラムで同じかどうかという質問をしたようです。」

ベストプラクティスに従うのが好きな人として、

コード メトリクスを実行した場合 (ソリューション エクスプローラーでプロジェクト名を右クリックし、[コード メトリクスの計算] - Visual Studio 2010) を選択します。

それは私に61の保守性指数を与えます

（もちろん、これしかない場合、これは重要ではありませんが、哲学がそのようなことをしているクラスのようなユーティリティを使用する場合、ユーティリティクラスの保守性指数は最悪になります..）

これに対する解決策は何ですか？