問題タブ [metrics]

コード/設計を検証するためにメトリクスをよく使用する人がいるかどうかを知りたいです。例として、私は使用すると思います：

• メソッドあたりの行数 (< 20)
• メソッドごとの変数の数 (< 7)
• メソッドあたりのパラメーター数 (< 8)
• クラスあたりのメソッド数 (< 20)
• クラスごとのフィールド数 (< 20)
• 継承ツリーの深さ (< 6)。
• メソッドのまとまりの欠如

これらの指標のほとんどは非常に単純です。

この種の対策については、どのようなポリシーをお持ちですか? ツールを使用して (NDepend など) チェックしていますか?

チームのソフトウェア開発プロセスを改善し、時間の見積もりを改善し、プロジェクトの実行中に対処する必要がある特殊なケースのバリエーションを検出するために使用できるメトリックを追跡したいと考えています。

各回答を 1 つの指標に限定し、その使用方法を説明し、良い回答に投票してください。

プロジェクト用の SVN リポジトリがあります。コード、ドキュメント、グラフなどを保持します。プロジェクトに関連するものはすべてそこにあり、バージョン管理されています。ただし、コードのある種のインテリジェントな統計を取得しようとしています。私が使用している統計プログラムは StatSVN です。私が知る限り、それらは最高の組み合わせのようです。ただし、古いファイル、Word ファイルなどの結果を取得していますが、これらの結果はグラフを歪めています。

これと戦い、私の cpp ファイルに関する信頼できる一連の情報を取得するためのアイデアはありますか? レポを再構築したいだけではありませんが、現時点ではそれが最善のアイデアかもしれないと心配しています...

最近、私たちの会社は、コード内の関数の循環的複雑度 (CC) を毎週測定し、どの関数が改善または悪化したかを報告し始めました。そのため、関数の CC にもっと注意を払うようになりました。

CC は、1 + 関数内の決定点の数 (if ステートメント、for ループ、select など)、または関数を通るパスの数として非公式に計算できることを読みました...

CC を減らす最も簡単な方法は、Extract Method リファクタリングを繰り返し使用することだと理解しています...

不明な点があります。たとえば、次のコード フラグメントの CC は何ですか?

1)

と

どちらも同じことを行いますが、for ステートメントのために最初のバージョンの方が CC が高くなりますか?

2)

と

言語が C# などの短絡評価を行うと仮定すると、これら 2 つのコード フラグメントは同じ効果を持ちますが、3 つの決定点/if ステートメントがあるため、最初のフラグメントの CC は高くなりますか?

3)

と

これら 2 つのコード フラグメントは異なることを行いますが、CC は同じですか? または、最初のフラグメントのネストされた if ステートメントの CC が高いですか? つまり、ネストされた if ステートメントは理解するのが精神的により複雑ですが、それは CC に反映されていますか?

Someone told me about swamp diagrams explaning that they were useful to predict code quality by measuring the rate of incoming defects and outgoing fixes on a given product.

Unfortunately, I am unable to find additional information on those diagrams and I am wondering if it is a jargon term specific to one company.

Can you explain what a swamp diagram is?

LOC (コードの行数) はコードの複雑さの測定に問題がありますが、最も一般的なものであり、非常に注意深く使用すると、少なくともコード ベースの相対的な複雑さを大まかに見積もることができます (つまり、1 つのプログラムが 10KLOC の場合)。もう 1 つは 100KLOC で、ほぼ同じ能力を持つチームによって同じ言語で書かれています。2 番目のプログラムはほぼ確実にはるかに複雑です)。

コードの行数を数える場合、コメントを で数えるのが好きですか? テストはどうですか？

これに対するさまざまなアプローチを見てきました。cloc や sloccount などのツールを使用すると、コメントを含めたり除外したりできます。コメントはコードの一部であり、複雑であると考える人もいます。

単体テストにも同じジレンマがあり、テストされるコード自体のサイズに達することもあれば、それを超えることさえあります。

「操作可能な」非コメント非空白行のみをカウントすることから、「テスト済みのコメント付きコードの XXX 行」まで、さまざまなアプローチを見てきました。事業"。

あなたの個人的な好みは何ですか? その理由は何ですか?

将来の従業員に、Java や C# などの特定のプログラミング言語で生涯に書かれたコードの行数を提供するよう要求した企業の 1 つ。私たちのほとんどは、複数の言語でのさまざまなプロジェクトで長年の経験があり、これをほとんど記録していないため、この指標を計算するための最良の方法は何でしょうか. stackoverlow.com の賢明なメンバーには、いくつかのアイデアがあると確信しています。

これはその分野で非常に尊敬されている会社であり、この質問をする非常に正当な理由があると確信しています. しかし、答えを難しくしているのは、考慮すべきコードの種類です。私が実装した難しいアルゴリズムや、たとえば 300 個のプロパティを持ち、ゲッター/セッターが IDE を使用して生成された POJO 用に書いたコードだけを含める必要があります。

私が知っているほとんどのプログラミング会社/マネージャーは、振り返ってみると、作成/解決されたバグの数という観点からのみ品質を定義できます。

ただし、ほとんどの優れたプログラマーは、コードをいじり始めると、本質的に品質を感じることができます。（右？）

あなたが知っているプログラミング会社は、この情報を組織が品質を確保するために測定および追跡できるメトリックに正常に変換しましたか？

不満を持ったマネージャーから、実際の品質に指を置くことができないという怒鳴り声をよく耳にするので、私は尋ねます。しかし、HoneyWellのような一部の組織には、プログラマーのパフォーマンスを追跡するための数値がたくさんあります。これらはすべて数値に変換され、評価中にチェックマークを付けることができます。したがって、コミュニティ全体に、彼らが知っている統計を引き出すための私の質問です。

厄介なコードをうまく測定できるツールに関する提案も役立ちます。

コマンド ラインを使用して C# プロジェクトのコード行のメトリックを取得するのに役立つ無料のツールをいくつか提案してください。

NLOC (netto lines of code) をカウントする簡単なスクリプトを知っていますか。スクリプトは C コードの行をカウントする必要があります。空行や中括弧だけの行を数えるべきではありません。しかし、過度に正確である必要もありません。