14

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

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

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

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

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

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

4

8 に答える 8

20

ある賢者は、プログラマーの管理に関しては「自分が測定した結果が得られる」と私に言ったことがあります。

LOC出力でそれらを驚くほど評価すると、多くのコード行が得られる傾向があります.

彼らが解決したバグの数で評価すると、驚くべきことに多くのバグが修正されます。

追加された機能を評価すると、多くの機能が得られます。

それらを循環的複雑度で評価すると、途方もなく単純な関数が得られます。

最近のコード ベースの主な問題の 1 つは、コード ベースの成長の速さと、成長したコードを変更するのがいかに難しいかということであるため、私は LOC をメトリックとして使用することをためらう傾向があります。 .

とはいえ、それを使用する必要がある場合は、sans コメントとテストを数え、一貫したコーディング スタイルを要求します。

しかし、本当に「コード サイズ」の測定が必要な場合は、コード ベースを tar.gz するだけです。さまざまなプログラミング スタイルの影響を受けやすい行を数えるよりも、「コンテンツ」の概算として役立つ傾向があります。

于 2008-11-08T10:50:17.103 に答える
9

テストとコメントも維持する必要があります。LOC をメトリックとして使用する場合 (そして、私はそれについて話すことができないと仮定します)、3 つすべて (実際のコード行、コメント、テスト) を提供する必要があります。

最も重要な (そしてできれば明らかな) ことは、一貫性を保つことです。実際のコード行だけを含む 1 つのプロジェクトと、3 つすべてを組み合わせた別のプロジェクトを報告しないでください。このプロセスを自動化し、レポートを生成するツールを検索または作成します。

Lines of Code:       75,000
Lines of Comments:   10,000
Lines of Tests:      15,000
                  ---------
Total:              100,000

そうすれば、確実にそうなるでしょう

  1. 終わらせる。
  2. 毎回同じように仕上げます。
于 2008-11-08T12:49:58.140 に答える
2

個人的には、LOC メトリック自体が他のコード メトリックほど有用であるとは思いません。

NDependは LOC メトリックを提供しますが、サイクロメトリックの複雑さなど、他の多くのメトリックも提供します。それらをすべてリストするのではなく、リストへのリンクを次に示します。

Reflector用の無料のCodeMetric アドインもあります

于 2008-11-08T10:11:26.463 に答える
1

単純な理由で、あなたの質問に直接答えるつもりはありません。コードの行数が嫌いだからです。何を測定しようとしても、LOC よりも悪い結果を出すのは非常に困難です。あなたが考えたい他のほとんどの指標は、より良いものになるでしょう.

特に、コードの複雑さを測定したいようです。全体的なサイクロメトリック複雑度(McCabe の複雑度とも呼ばれます) は、このためのはるかに優れたメトリックです。

サイクロメトリックの複雑さが高いルーチンは、注意を向けたいルーチンです。これらのルーチンは、テストが難しく、バグでコアまで腐敗し、保守が困難です。

この種の複雑さを測定する多くのツールがあります。お気に入りの言語で Google をすばやく検索すると、このような複雑な処理を行うツールが多数見つかります。

于 2008-11-08T10:15:42.353 に答える
1

コードの行数は、まさに次のことを意味します。コメントや空行はカウントされません。そして、それを他のソース コードと比較できるようにするために (そのメトリックが役立つかどうかに関係なく)、少なくとも同様のコーディング スタイルが必要です。

for (int i = 0; i < list.count; i++)
{
    // do some stuff
}

for (int i = 0; i < list.count; i++){
    // do some stuff
}

2 番目のバージョンもまったく同じですが、LOC が 1 つ少なくなっています。ネストされたループが多数ある場合、これはかなりの量になります。これが、ファンクション ポイントのようなメトリクスが発明された理由です。

于 2008-11-08T10:23:24.740 に答える
0

コード行数メトリックを使用するのは、1 つのことだけです。関数には、画面をスクロールせずに読み取れるだけの十分な数のコード行が含まれている必要があります。それよりも大きな関数は、サイクロメトリックな複雑度が非常に低い場合でも、通常は読みにくいものです。彼の使用のために、空白とコメントを数えます。

また、リファクタリング中に削除したコードの行数を確認することもできます。ここでは、実際のコード行、読みやすさに役立たない空白、および役に立たないコメントのみをカウントします (これはできません)。自動化されます）。

最後に免責事項 - メトリックを賢く使用してください。メトリクスをうまく利用すると、「コードのどの部分がリファクタリングによって最も恩恵を受けるか」または「最新のチェックインのコード レビューはどれくらい緊急か」という質問に答えることができます。- 循環的複雑度が 50 の 1000 行関数は、「今すぐリファクタリングしてください」というネオン サインの点滅です。メトリクスの悪い使い方は、「プログラマー X の生産性」または「私のソフトウェアの複雑さ」です。

于 2009-08-20T18:18:59.807 に答える
0

記事からの抜粋: How do you count your number of Lines Of Code (LOC) ? .NET プログラムのコードの論理行数をカウントするツール NDepend に関連しています。

コードの行数 (LOC) をどのように数えますか?

メソッド署名宣言をカウントしますか? 括弧だけで行数を数えますか? パラメーターの数が多いために 1 つのメソッド呼び出しが複数の行に記述されている場合、複数の行を数えますか? 「名前空間」と「名前空間の使用」宣言を数えますか? インターフェイスと抽象メソッドの宣言をカウントしますか? 宣言されたときにフィールドの割り当てを数えますか? 空行は数えますか？

各開発者のコ​​ーディング スタイルと、選択した言語 (C#、VB.NET など) に応じて、LOC を測定することで大きな違いが生じる可能性があります。

ソース ファイルの解析から LOC を測定することは、明らかに複雑なテーマのように見えます。洞察力のおかげで、論理 LOC と呼ばれるものを正確に測定する簡単な方法が存在します。論理 LOC には、物理​​ LOC (ソース ファイルの解析から推測される LOC) よりも 2 つの大きな利点があります。

  • コーディング スタイルは、論理 LOC に干渉しません。たとえば、引数の数が多いためにメソッド呼び出しが複数の行で生成されるため、LOC は変更されません。
  • 論理 LOC は言語に依存しません。異なる言語で記述されたアセンブリから取得した値は比較可能であり、合計できます。

.NET の世界では、論理 LOC は PDB ファイル (デバッガーが IL コードをソース コードにリンクするために使用するファイル) から計算できます。ツール NDepend は、メソッドの論理 LOC を次のように計算します。これは、PDB ファイル内のメソッドで見つかったシーケンス ポイントの数に等しくなります。シーケンス ポイントは、元のソースの特定の位置に対応する IL コードのスポットをマークするために使用されます。シーケンス ポイントの詳細については、こちらをご覧ください。C# の中かっこ '{' と '}' に対応するシーケンス ポイントは考慮されないことに注意してください。

明らかに、型の LOC はそのメソッドの LOC の合計であり、名前空間の LOC はその型の LOC の合計であり、アセンブリの LOC はその名前空間の LOC の合計であり、アプリケーションの LOC は次のとおりです。アセンブリ LOC の合計。ここにいくつかの観察があります：

  • インターフェイス、抽象メソッド、および列挙の LOC は 0 に等しくなります。LOC の計算時には、効果的に実行される具体的なコードのみが考慮されます。
  • 名前空間、型、フィールド、およびメソッドの宣言は、対応するシーケンス ポイントがないため、コード行とは見なされません。
  • C# または VB.NET コンパイラがインライン インスタンス フィールドの初期化に直面すると、インスタンス コンストラクターごとにシーケンス ポイントが生成されます (インライン静的フィールドの初期化と静的コンストラクターにも同じことが当てはまります)。
  • 匿名メソッドから計算された LOC は、その外側の宣言メソッドの LOC に干渉しません。
  • NbILInstructions と LOC (C# および VB.NET の場合) の全体的な比率は、通常約 7 です。
于 2010-08-30T16:46:33.920 に答える
0

LOCを何に使用しているかによって異なります。

複雑さの尺度として - それほどではありません。おそらく、100KLOC はほとんどが単純なテーブルから生成されたコードであり、10KLOC kas は 5KLOC 正規表現です。

ただし、ランニング コストに関連するすべてのコード行が表示されます。プログラムが存続している限り、すべての行に対して料金が発生します。保守時に読み取る必要があり、修正が必要なエラーが含まれている可能性があり、変更前のコンパイル時間、ソース管理からの取得、およびバックアップ時間が増加します。またはそれを削除するなど、誰かがそれに依存しているかどうかを調べる必要があるかもしれません.

KLOC は、プロジェクトに必要なインフラストラクチャの量を示す最初の指標となる可能性があります。その場合、コメントとテストを含めます - コメント行の実行コストは、2 番目のプロジェクトの正規表現の 1 つよりもはるかに低くなりますが。

[編集] [コードサイズについて同様の意見を持つ人] 1

于 2008-11-08T13:22:05.627 に答える