lines-of-code - コードの行を数える標準的な方法はありますか？

Question

この質問に対する明確な「正しい」答えはないことを私は理解していますが、人々がコード行について話すとき、それらはどういう意味ですか？たとえば、C ++では、空白行を数えますか？コメント？開いたブレースまたは閉じたブレースだけの線？

生産性の尺度としてコード行を使用する人がいることは知っていますが、ここに標準的な規則があるかどうか疑問に思っています。また、さまざまなコンパイラにコードの行をカウントさせる方法があると思います-そこに標準的な規則はありますか？

score 23 · Accepted Answer

いいえ、標準的な規則はありません。それらをカウントするすべてのツールはわずかに異なります。

これにより、「では、なぜ LOC を生産性の尺度として使用するのでしょうか?」と疑問に思うかもしれません。答えは、コードの行をどのように数えるかは実際には問題ではないため、それらを一貫して数えている限り、他のプロジェクトと比較したプロジェクトの一般的なサイズについてある程度のアイデアを得ることができるからです。

score 14 · Accepted Answer

ウィキペディアの記事、特に「SLOC の測定」セクションをご覧ください。

SLOC 対策には、物理 SLOC と論理 SLOC の 2 つの主要なタイプがあります。これら 2 つの尺度の具体的な定義は異なりますが、物理 SLOC の最も一般的な定義は、コメント行を含むプログラムのソースコードのテキスト内の行数です。セクション内のコード行が 25% を超える空白行で構成されていない限り、空白行も含まれます。この場合、25% を超える空白行はコード行としてカウントされません。

論理 SLOC 測定では「ステートメント」の数を測定しようとしますが、その特定の定義は特定のコンピューター言語に関連付けられています (C に似たプログラミング言語の単純な論理 SLOC 測定の 1 つは、ステートメントを終了するセミコロンの数です)。物理 SLOC を測定するツールを作成するのははるかに簡単で、物理 SLOC の定義は簡単に説明できます。ただし、物理的な SLOC メジャーは、論理的に無関係な書式設定やスタイルの規則に敏感ですが、論理的な SLOC は、書式設定やスタイルの規則にはそれほど敏感ではありません。残念ながら、SLOC の測定値は定義を与えずに記述されることが多く、論理 SLOC は物理 SLOC と大きく異なることがよくあります。

SLOC を決定する際に発生するあいまいさの例として、次の C コードのスニペットを検討してください。
for (i=0; i<100; ++i) printf("hello");   /* How many lines of code is this? */
この例では、次のものがあります。

コード LOC の 1 物理行

コードの 2 つの論理行 lLOC (ステートメントおよび printf ステートメント用)

1 コメント行

[...]

score 8 · Accepted Answer

私は言うだろう

コメント数
空白行は読みやすさにとって重要であるため重要ですが、連続して1行を超えることはできません。
中括弧のある行もカウントされますが、空白行の場合と同じルールを適用します。つまり、間にコードがない5つのネストされた中括弧は1行としてカウントされます。

また、実際にLoC値に依存する生産性測定値は2つであることを謙虚に提案します:)

score 4 · Accepted Answer

4

「wc-l」が返すものはすべて私の番号です。

于 2008-12-09T16:36:23.077 に答える

score 4 · Accepted Answer

より少ないコード行で終了できる日はいつでも、機能は同じかより多く機能します... 良い日です。何百行ものコードを削除して、同じように機能し、より保守しやすいものに仕上げることができるのは素晴らしいことです。

そうは言っても、チーム内に非常に厳密なコーディングガイドラインがない限り、物理的なコード行は役に立たない統計値です。論理的なコード行はまだ役に立ちませんが、少なくとも危険なほど誤解を招くものではありません。

score 2 · Accepted Answer

「コード行」には、維持する必要があるものをすべて含める必要があります。これにはコメントが含まれますが、空白は除外されます。

これを生産性の指標として使用している場合は、合理的な比較を行っていることを確認してください。C++ の行は、Ruby の行と同じではありません。

score 2 · Accepted Answer

1 行 = 読み取りの 4 秒。その行で私が言っていることを理解するのにそれ以上かかる場合は、行が長すぎます.

score 2 · Accepted Answer

生産性の尺度として LOC を使用すると、プログラマーが「システムを操作する」ためにはるかに冗長に記述していることに突然気付くでしょう。それはばかげた手段であり、自慢する権利以外の目的でそれを使用するのは愚かな人々だけです.

score 1 · Accepted Answer

LOC はあいまいな指標であることで有名です。詳細な比較については、同じ言語、同じスタイル、同じチームによって記述されたコードを比較する場合にのみ有効です。

ただし、桁違いのアイデアで見ると、特定の複雑さの概念が提供されます。10000 行のプログラムは、100 行のプログラムよりもはるかに複雑です。

LOC の利点は、wc -l がそれを返すことであり、他の多くのソフトウェアメトリクスとは異なり、LOC の理解や計算に特別な手間がかからないことです。

score 1 · Accepted Answer

正解はありません。

非公式の見積もりには、wc -l を使用します。

何かを厳密に測定する必要がある場合は、実行可能なステートメントを測定します。ほとんど、ステートメント終了文字 (通常はセミコロン) があるもの、またはブロックで終わるもの。複合ステートメントの場合、各サブステートメントを数えます。

そう：

int i = 7;                  # one statement terminator; one (1) statement
if (r == 9)                # count the if as one (1) statement
  output("Yes");      # one statement terminator; one (1) statement; total (2) for the if
while (n <= 14) {    # count the while as one (1) statement
  output("n = ", n);  # one statement terminator; one (1) statement
  do_something();   # one statement terminator; one (1) statement
  n++                       # count this one, one statement (1), even though it doesn't need a statement terminator in some languages
}                              # brace doesn't count; total (4) for the while

もし私がそれをSchemeやLispでやっていたら、私は式を数えるだろう.

他の人が言ったように、最も重要なことは、カウントが一貫していることです. また、これを何に使用するかも重要です。潜在的な新入社員にプロジェクトの規模を知らせたい場合は、wc -l を使用します。計画と見積もりを行いたい場合は、より形式的なものを使用することをお勧めします。いかなる状況においても、LOC を使用してプログラマーの補償を基にするべきではありません。

score 1 · Accepted Answer

「生成されたコード行」ではなく、「消費されたコード行」を考えるべきです。

物事は可能な限り単純であるべきなので、行数に基づいてポジティブなベンチマークを作成すると、悪いコードが助長されます。

さらに、非常に難しいことはごくわずかなコードで解決してしまうこともあれば、非常に簡単なこと (getter や setter などのボイラープレートコードなど) は、非常に短い時間で多くの行を追加できます。

元の質問に関しては、行を数える場合は、連続した空白行以外のすべての行を含めます。コメントも (願わくば) 役に立つドキュメントなので、コメントを含めたいと思います。

score 1 · Accepted Answer

LOC の概念は、コードの量を定量化する試みです。他の回答で指摘されているように、一貫性がある限り、コード行を具体的に何と呼ぶかは問題ではありません。直感的には、1000 行のプログラムよりも小さい 100 行のプログラムよりも小さい 10 行のプログラムのように見えます。1000 行のプログラムよりも 100 行のプログラムを作成、deubg、および維持するのにかかる時間が短いことが予想されます。少なくとも非公式には、LOC を使用して、特定のサイズのプログラムを作成、デバッグ、および維持するために必要な作業量を大まかに把握できます。

もちろん、これが通用しないところもあります。たとえば、1000 行でレンダリングされる複雑なアルゴリズムは、たとえば 2500 行を消費する単純なデータベースプログラムよりも開発がはるかに難しい場合があります。

したがって、LOC は、管理者が問題のサイズを合理的に把握できるようにするコード量の粗粒度の尺度です。

score 0 · Accepted Answer

.NETの世界では、コード行（LoC）がデバッグシーケンスポイントであるという世界的な合意があるようです。シーケンスポイントはデバッグの単位であり、ブレークポイントを設定するときに暗赤色で強調表示されるコード部分です。シーケンスポイントを使用すると、論理LoCについて話すことができ、このメトリックはさまざまな.NET言語間で比較できます。論理LoCコードメトリックは、VisualStudioコードメトリック、NDepend、NCoverなどのほとんどの.NETツールでサポートされています。

8 LoCメソッド（開始および終了ブラケットのシーケンスポイントは考慮されません）：

代替テキスト

物理的なLoC（ソースファイルの行数を数えることを意味する）とは異なり、論理的なLoCには、コーディングスタイルに依存しないという大きな利点があります。コーディングスタイルは、私たち全員が同意しますが、物理的なLoCカウントを、開発者ごとに桁違いに変化させることができます。このトピックに関するより詳細なブログ投稿を書きました：コード行（LOC）の数をどのように数えますか？

score 0 · Accepted Answer

生産性の尺度としてLoCを使用している人がいることを私は知っています

私が誤って彼らと一緒に（またはさらに悪いことに）彼らと一緒に仕事をしないように、彼らが誰であるかを教えていただけますか？

Haskellを使用して1400行で実装できる場合、Cを使用して2800行で実装できるものを、CまたはHaskellでより生産的にすることができますか？どちらが時間がかかりますか？バグが増えるのはどれですか（ヒント：LOCカウントでは線形です）？

プログラマーの価値は、彼のコードがどれだけ変更されるか（空の文字列から、または空の文字列への変更を含む）によって、収益の数値が増えることです。私はそれを測定または概算する良い方法を知りません。しかし、合理的に測定可能なメトリックはゲーム化でき、実際に必要なものを反映していないことを私は知っています。したがって、使用しないでください。

そうは言っても、LOCをどのように数えますか？シンプル、使用wc -l。なぜそれが正しいツールなのですか？ええと、あなたはおそらく特定の数を気にしないでしょうが、一般的な全体の傾向（上昇または下降、そしてどれだけ）、個々の傾向（上昇または下降、方向を変える速さなど）について、そして約82,763という数字以外はほとんど何でも。

ツールが測定するものの違いはおそらく興味深いものではありません。あなたのツール（そしてそのツールだけ）によって吐き出された数が何か面白いものと相関しているという証拠がない限り、それを大まかな球場の数字として使用してください。単調性以外のものは、穀物だけでなく、バケツ一杯の塩で摂取する必要があります。

発生回数を数え'\n'ます。カウントする他の興味深い文字は、、';'および'{'です'/'。

score 0 · Accepted Answer

LOCphy:物理的な線
LOCbl: Blanklines Kommentarblocks werden als Kommentarzeile gezählt
LOCpro:プログラミング行 (宣言、定義、ディレクティブ、およびコード)
LOCcom:コメント行

多くの利用可能なツールは、塗りつぶされた行のパーセンテージなどの情報を提供しています。

あなたはそれを見なければなりませんが、それを当てにするだけではありません。

LOC はプロジェクトの開始時に大幅に増加し、レビュー後に頻繁に減少します ;)

score 0 · Accepted Answer

私はそれを単一の処理可能なステートメントと考えています。例えば

(1行)

Dim obj as Object

(5行)

If _amount > 0 Then
  _amount += 5
Else
  _amount -= 5
End If

score 0 · Accepted Answer

多くの方法で報告されており、重要な指標ではないという投稿に同意します. これまでに耳にしたことのある開発者向けのコードを参照してください。

score 0 · Accepted Answer

wc -lワークスペースの複雑さを簡単に見積もるために使用します。ただし、生産性指標としての LOC は最悪です。if LOCカウントがダウンした場合、私は一般的に非常に生産的な日だと考えています.

score 0 · Accepted Answer

Craig H の受け入れられた回答に同意しますが、学校で、コード行の測定に関して、空白、コメント、および宣言を「コード行」として数えるべきではないと教えられたことを付け加えたいと思います。プログラマーが生産性向上のために作成したものです。つまり、Ol の「1 日あたり 15 行」というルールです。

score 0 · Accepted Answer

この作業には cloc ツールを強くお勧めします。多くの言語の行を数えます。

https://github.com/AlDanial/cloc#quick-start-

当社で使用し、このツールが気に入りました。出力から ss を共有します。

lines-of-code - コードの行を数える標準的な方法はありますか？

21 に答える 21

Related

Reference