metrics - 「コードの行数」が有用な指標になるのはいつですか?

Question

コードの最大の敵はそのサイズだと主張する人もいますが、私もそう思う傾向があります。それでも毎日、次のようなことを聞き続けます

私は一日で何行ものコードを書きます。
私は x 行のコードを所有しています。
Windows は数百万行のコードです。

質問: 「#lines of code」はどのような場合に役立ちますか?

追伸: そのような発言がなされるとき、口調は「多いほど良い」であることに注意してください。

score 112 · Accepted Answer

プロジェクトの実行を改善するためにコードを削除しているときだと思います。

「X行数」を削除したと言うのは印象的です。そして、コード行を追加するよりもはるかに役に立ちます。

score 51 · Accepted Answer

誰もダイクストラの有名な引用にまだ言及していないことに驚いたので、以下に示します。

今日の私のポイントは、コードの行数を数えたいのであれば、それを「生成された行」ではなく「消費された行」と見なすべきだということです。元帳。

引用は、「コンピューティングサイエンスを実際に教えることの残酷さについて」という記事からのものです。

score 37 · Accepted Answer

これはひどい測定基準ですが、他の人が指摘しているように、システムの全体的な複雑さについて（非常に）大まかなアイデアが得られます。2つのプロジェクトAとBを比較していて、Aが10,000行のコードで、Bが20,000行である場合、それはあまりわかりません。プロジェクトBが過度に冗長であるか、Aが超圧縮されている可能性があります。

一方、一方のプロジェクトが10,000行のコードで、もう一方のプロジェクトが1,000,000行の場合、一般に、2番目のプロジェクトはかなり複雑になります。

このメトリックの問題は、生産性またはプロジェクトへの貢献度を評価するために使用される場合に発生します。プログラマー「X」がプログラマー「Y」の2倍の行数を書き込んだ場合、彼はもっと貢献しているかもしれないし、そうでないかもしれません-多分「Y」はより難しい問題に取り組んでいます...

score 29 · Accepted Answer

29

友達に自慢するとき。

于 2008-10-08T18:16:39.687 に答える

score 28 · Accepted Answer

少なくとも、進歩のためではありません:

「プログラミングの進捗状況をコード行で測定することは、航空機の製造の進捗状況を重量で測定するようなものです。」 - ビルゲイツ

score 21 · Accepted Answer

私が非常に貴重だと思う特別なケースが 1 つあります。面接で、あなたの仕事の一部は既存の C++/Perl/Java などを維持することだと彼らがあなたに言ったとき。レガシープロジェクト。インタビュアーにレガシープロジェクトに関与している KLOC (おおよそ) の数を尋ねると、彼らの仕事が欲しいかどうかについてより良いアイデアが得られます。

score 19 · Accepted Answer

これは、ラインプリンタをロードするときに役立ちます。これにより、印刷しようとしているコードリストが何ページを消費するかを知ることができます。;)

score 10 · Accepted Answer

これを思い出します：

短くする暇がなかったので、この手紙はとても長いものです。
――ブレーズ・パスカル

score 9 · Accepted Answer

ほとんどの指標と同様に、コンテキストがなければほとんど意味がありません。つまり、簡単な答えは次のとおりです。決して（ラインプリンターを除いて、それは面白いです！最近、誰がプログラムを印刷しますか？）

例：

レガシーコードの単体テストとリファクタリングを行っていると想像してみてください。それは、50,000行のコード（50 KLOC）と1,000の実証可能なバグ（単体テストの失敗）から始まります。この比率は、1K / 50KLOC=50行のコードあたり1つのバグです。明らかにこれはひどいコードです！

さて、数回の反復の後、模範的なリファクタリングにより、既知のバグを半分に（そして未知のバグをそれ以上に）削減し、コードベースを5分の1に削減しました。この比率は、500/10000=20行のコードあたり1つのバグになりました。これは明らかにさらに悪いです！

作成したい印象に応じて、これは次の1つ以上として表示できます。

バグが50％少ない
5分の1のコード
コードが80％少ない
バグとコードの比率が60％悪化

これらはすべて真実であり（私が数学を台無しにしなかったと仮定して）、そのようなリファクタリングの努力が達成したに違いない大幅な改善を要約するのはすべて嫌です。

score 7 · Accepted Answer

25年ほど前に読んだ引用を言い換えると、

「コード行を指標として使用する際の問題は、問題の複雑さではなく、ソリューションの複雑さを測定することです」.

この引用は、Journal of the ACM の記事で David Parnas からのものだと思います。

score 5 · Accepted Answer

さまざまなソフトウェアメトリクスがあります。コード行が最もよく使用され、最も理解しやすいものです。

コード行のメトリックが他のメトリックと相関する頻度に驚いています。循環的複雑度を計算してコードの臭いを検出できるツールを購入する代わりに、行数の多いメソッドを探すだけで、複雑度も高くなる傾向があります。

コード行の使用の良い例は、メトリックにあります：コード行あたりのバグ。これにより、プロジェクトで見つかると予想されるバグの数を直感的に把握できます。私の組織では、通常、1000行のコードあたり約20個のバグがあります。つまり、100,000行のコードを含む製品を出荷する準備ができており、バグデータベースに50個のバグが見つかった場合は、さらにテストを行う必要があります。1000行のコードあたり20個のバグがある場合、おそらく通常の品質に近づいています。

悪い使用例は、開発者の生産性を測定することです。開発者の生産性をコード行で測定する場合、人々はより多くの行を使用してより少ない配信を行う傾向があります。

score 4 · Accepted Answer

回答: コードの負の行について話すことができるとき。例: 「今日、不要なコードを 40 行削除しましたが、プログラムは以前と同じように機能しています。」

score 3 · Accepted Answer

プロジェクトのコードの合計行数を取得することが、複雑さを測定する1つの方法であることに同意します。

確かに、それは複雑さの唯一の尺度ではありません。たとえば、100行の難読化されたPerlスクリプトのデバッグは、コメントテンプレートを使用した5,000行のJavaプロジェクトのデバッグとは大きく異なります。

しかし、ソースを見ずに、10MBのソースtarballが15kbのソースtarballよりも複雑であると思うのと同じように、通常、コードの行数が多いほど複雑であると思うでしょう。

score 3 · Accepted Answer

多くの点で便利です。

正確な # は覚えていませんが、Microsoft は Web キャストを持っていて、コードの X 行ごとに平均して y 個のバグがあると説明していました。そのステートメントを使用して、いくつかのことのベースラインを与えることができます。

コードレビュアーの仕事ぶり。
複数のプロジェクトのバグ比率を比較して、2 人の従業員のスキルレベルを判断します。

もう 1 つ注目する点は、なぜこれほど多くの行があるのかということです。多くの場合、新しいプログラマーが行き詰まると、関数を作成してカプセル化する代わりに、コードのチャンクをコピーして貼り付けるだけになります。

1 日に x 行のコードを書いたというのは、ひどい尺度だと思います。問題の難しさ、書く言語などは考慮されていません。

score 3 · Accepted Answer

特定のプロジェクトから頭のてっぺんから参照できるコード行数には限りがあるように思えます。制限は、平均的なプログラマーにとっておそらく非常に似ています。したがって、プロジェクトに 200 万行のコードがあることがわかっていて、プログラマーがよく知っている 5,000 行のコードにバグが関連しているかどうかを理解できると期待できる場合、400 人を雇う必要があることがわかります。コードベースのプログラマーが誰かの記憶から十分にカバーされるようにします。

これにより、コードベースの成長が速すぎることを再考し、より理解しやすくするためにコードベースをリファクタリングすることを考えるようになるかもしれません。

これらの数字は私が作ったことに注意してください。

score 3 · Accepted Answer

Software Engineering Institute の Process Maturity Profile of the Software Community: 1998 Year End Update (残念ながらリンクが見つかりませんでした) では、約 800 のソフトウェア開発チーム (またはおそらくショップ) の調査について説明しています。平均欠陥密度は、1000 LOC あたり 12 個の欠陥でした。

欠陥が 0 個のアプリケーションがあり (実際には存在しませんが、仮定しましょう)、平均で 1000 個の LOC を書き込んだ場合、システムに 12 個の欠陥が導入されたと想定できます。QA が 1 つまたは 2 つの欠陥を見つけた場合、それでおしまいです。おそらく 10 以上の欠陥があるため、さらにテストを行う必要があります。

score 2 · Accepted Answer

ほとんどの人がすでに述べているように、特に異なる言語でコーディングしている人を比較している場合、それはあいまいなメトリックになる可能性があります。

Lispの5,000行！=Cの5,000行

score 2 · Accepted Answer

注文する必要があるパンチカードの数の予算を立てなければならない場合。

score 2 · Accepted Answer

コードの行数 (LoC) をカウントすることの長所と短所を詳述した 2 つのブログ投稿を書きました。

コードの行数 (LOC) をどのように数えますか? : これは、物理的なコード行数ではなく、論理的なコード行数を数える必要があることを説明するためのものです。これを行うには、たとえばNDependなどのツールを使用できます。

コードの行数 (LOC) をカウントすると便利なのはなぜですか? : LoC は生産性の測定に使用すべきではなく、テストカバレッジの推定とソフトウェアの期限の推定に使用すべきであるという考え方です。

score 2 · Accepted Answer

コードファイルが大きくなりすぎていないかどうかを判断するには、コード行が役立ちます。うーん...このファイルは現在 5000 行のコードです。多分私はこれをリファクタリングする必要があります。

score 2 · Accepted Answer

これは、生産性と複雑さの指標です。すべての指標と同様に、慎重に評価する必要があります。通常、完全な回答を得るには、単一のメトリックでは不十分です。

IE では、500 行のプログラムは 5000 行ほど複雑ではありません。ここで、プログラムをよりよく理解するために他の質問をする必要があります...しかし、これで指標が得られました。

score 2 · Accepted Answer

これは、人々を怖がらせたり、感銘を与えたりするための優れた指標です。それはそれについてであり、間違いなく、これらの 3 つの例すべてに見られるコンテキストです。

score 1 · Accepted Answer

ウィキペディアの定義を確認してください：http：//en.wikipedia.org/wiki/Source_lines_of_code

SLOC='コードのソース行'

実際、私が働いているこれらの指標にはかなりの時間が費やされています。SLOCをカウントするさまざまな方法もあります。

ウィキペディアの記事から：

SLOCメジャーには、物理SLOCと論理SLOCの2つの主要なタイプがあります。

もう1つの優れたリソース：http ：//www.dwheeler.com/sloc/

score 1 · Accepted Answer

これらは、アプリケーションの規模を示すのに役立ちます。品質については何も述べていません。ここでの私のポイントは、1,000行のアプリケーションで作業していて、（おおよそ）500k行のアプリケーションがある場合、潜在的な雇用主は、大規模なシステムの経験と小規模なユーティリティプログラミングのどちらを持っているかを理解できるということです。

システムから削除するコードの行数は、追加する行よりも有用であるというウォーレンに完全に同意します。

score 1 · Accepted Answer

1

競技会で。

于 2008-10-08T18:34:09.747 に答える

score 1 · Accepted Answer

コーダーがコードの行数を数えていることを知らない場合、システムをゲーム化するために意図的に冗長なコードを追加する理由はありません。そして、チームの全員が同様のコーディングスタイルを持っている場合（したがって、行ごとの既知の平均「値」があります）。そして、より良い測定値が利用できない場合に限ります。

score 1 · Accepted Answer

変更に時間がかかる理由を指摘するとき。

「Windows は 700 万行のコードであり、すべての依存関係をテストするには時間がかかります...」

score 1 · Accepted Answer

コードベースをリファクタリングしていて、コード行を削除したことが示され、すべての回帰テストに合格した場合。

score 1 · Accepted Answer

コード行は実際にはあまり役に立ちません。管理者がそれを指標として使用すると、プログラマーはスコアを上げるために多くのリファクタリングを行うことになります。さらに、貧弱なアルゴリズムはきちんとした短いアルゴリズムに置き換えられません。これは、負の LOC カウントが発生して不利になるためです。正直に言うと、LOC/d を生産性指標として使用する会社で働くべきではありません。なぜなら、経営陣は明らかにソフトウェア開発について何の手がかりも持っていないため、初日から常に後手に回ることになるからです。

score 1 · Accepted Answer

努力のレベル (LOE) を決定するとき。提案をまとめていて、ほぼ同じエンジニアが新しいプロジェクトに取り組んでいる場合、何人のエンジニアがどのくらいの期間必要かを判断できる場合があります。

score 1 · Accepted Answer

欠陥数と関連付けると非常に便利な考え方です。「欠陥」は、コードの品質の尺度を示します。「欠陥」が少ないほど、ソフトウェアは優れています。すべての欠陥を取り除くことはほぼ不可能です。多くの場合、1 つの欠陥が有害で致命的となる可能性があります。

しかし、良品のソフトウェアは存在しないようです。

score 0 · Accepted Answer

前述の「自慢する」目的を除いて、機能的には決してありません。

行！=有効性。私の経験では、関係は逆であることがよくあります（ただし、厳密ではありませんが、特に極端な場合は、明らかな理由で）

score 0 · Accepted Answer

Microsoftは6か月ごとに5％の人を解雇していたと聞きましたが、それは書かれたコード行に基づいているといつも思っていました。そのため、Windowsは非常にかさばり、遅く、非効率的です;）。コード行は、大まかな順序でアプリケーションの複雑さを測定するための便利なメトリックです。つまり、Basicの初心者プログラムは10行のコード、100行のコードはおもちゃのアプリケーション、50000行は妥当なサイズのアプリケーション、10百万行のコードは、Windowsと呼ばれる怪物です。

コードの行はあまり有用なメトリックではありませんが、私はアセンブリ言語（主に68000）でゲームを作成し、約5万行のコードで測定していましたが、レジスタをプッシュしないことでコードの行数を抑えました。スタックし、レジスタに含まれているものを追跡してコードサイズを削減します（私が知っている他のプログラマーは、d0-d7、a0-a6の倍数をスタックにプッシュしました。これにより、コードの速度が明らかに低下しますが、追跡が簡単になります。影響を受けるもの）。

score 0 · Accepted Answer

これは、リスク評価の目的で非常に優れた複雑さの尺度になる可能性があります。変更される行が多いほど、バグが発生する可能性が高くなります。

score 0 · Accepted Answer

コード行は、さまざまなプロジェクトを比較するための有用なメトリックではありません。

ただし、プロジェクト内では、コードベースのサイズが時間の経過とともにどのように変化するかを監視するための移動図として役立つ場合があります。CIプロセスの一部として、各ビルドでのコード行を示すグラフを生成すると、プロジェクトがどのように進化しているかを視覚化するのに役立ちます。

この文脈でも、正確な「コード行」の図自体は重要ではないと私は主張します。有用なのは、トレンドの視覚化です。機能が追加されるにつれて、着実に上昇します。大きなプロジェクトが完了するジャンプ。少し冗長なコードが削除されたディップ。

score 0 · Accepted Answer

私はそれが2つの条件下で役立つことを発見しました：

コーディングの時間が短縮されたときに、自分の新しいプロジェクトで自分の生産性を測定します。
大企業で働いていて、実際には1日あたりのウィジェットしか理解していないマネージャーと話すとき。

score 0 · Accepted Answer

まず、生成されたコードを除外し、ジェネレーター入力のコードとジェネレーター自体を追加します。

次に、（皮肉なことに）コードのすべての行にバグが含まれている可能性があり、保守する必要があると言います。より多くのコードを維持するには、より多くの開発者が必要です。その意味で、より多くのコードはより多くの雇用を生み出します。

ユニットテストが少ないと一般的に保守性が向上しないため、上記のステートメントからユニットテストを除外したいと思います:)

score 0 · Accepted Answer

これは、販売プレゼンテーション中に頻繁に使用されます。たとえば、KLoC（Kilo Lines of Code）またはLoCは、ベンダー組織が大規模/複雑なシステムに対して持つ能力の種類を示すために使用されます。これは、ベンダーが複雑なレガシーシステムを維持する能力を披露しようとしている場合に特に当てはまります。交渉の一環として、顧客組織がベンダーと概念実証を実行してベンダーの機能をテストするための代表的なコードのチャンクを提供する場合があります。この代表的なコードには、ベンダー企業が処理するのに十分な複雑さと、「維持」に関するセールスピッチがあります。数百万のLoC"を備えたシステムが監視対象になる可能性があります。

したがって、はい、Lines of Codeは販売プレゼンテーション中に使用および乱用されるため、販売において有用な指標となります。

score 0 · Accepted Answer

LOC の数は、欠陥率 (1,000 LOC あたりのバグなど) を計算するときに役立ちます。

score 0 · Accepted Answer

コード行数は、コード行数が製品サイズの一般的な指標であると考えている顧客に、包括的な製品の拡張性を売り込む場合に役立ちます。たとえば、あなたの製品が多くの特殊なケースを処理することを誰かに納得させようとしているとき、またはツールベンダーがテスト目的で最大限のコードカバレッジを得たいと考えている開発ツールのベータ版に入ろうとしているときなどです。

score 0 · Accepted Answer

特定のタスクに追加されるコードの数は、誰がコードを書いているかによって大きく異なります。生産性の尺度として使用すべきではありません。特定の個人が 1000 行の冗長で複雑ながらくたを生成する可能性がありますが、別の個人は 10 行の簡潔なコードで同じ問題を解決できます。メトリックとして追加された LOC を使用しようとするときは、「誰が」という要因も考慮する必要があります。

実際に役立つメトリックは、「追加された行数に対して検出された欠陥の数」です。これにより、特定のチームまたは個人のコーディング能力とテストカバレッジ能力を知ることができます。

他の人も指摘しているように、削除されたLOCは、追加されたLOCよりも自慢する権利があります:)

score 0 · Accepted Answer

コード行は言語によって異なります。

たとえば、C コードの 1 行は、ASM コードの平均 x 行に相当します。C++ の 1 行 -> C など....

Java と C# は、VM からのバックグラウンドサポートにより、かなりの数のコード行をカプセル化します。

score 0 · Accepted Answer

これは主に、すでに大量の解説への追加です..しかし、基本的に、コード行 (またはおそらく totalCharacterCount/60) はモンスターのサイズを示します。何人かの人が言っているように、これはコードベースの複雑さの手がかりになります。その複雑さのレベルは大きな影響を与えます。部分的には、システムを理解して変更を加えることがいかに難しいかに影響します。

これが、人々がより少ないコード行を望む理由です。理論的には、コード行が少ないほど複雑さが軽減され、エラーの余地が少なくなります。事前に知っておくことが、見積もりと計画以外の場合に非常に役立つかどうかはわかりません。

例: 私がプロジェクトを持っていて、大雑把に調べてみると、10,000 行のアプリケーション内で 1000 行ものコードを変更する必要があることがわかりました。このプロジェクトは、実装に時間がかかり、安定性が低くなり、デバッグとテストに時間がかかる可能性が高いことを知っています.

また、2 つのビルド間の変更の範囲を理解するのにも非常に役立ちます。任意の 2 つの SVN リビジョン間の変更範囲を分析する小さなプログラムを作成しました。統一された差分を見て、そこから、追加、削除、または変更された行の数を把握します。これは、新しいビルドに続くテストと QA で何が期待できるかを知るのに役立ちます。基本的に、変更の数が多いということは、そのビルドを詳しく監視したり、完全な回帰テストを実施したりする必要があることを意味します.

score 0 · Accepted Answer

言語を比較するときに役立ちます。Groovy と Clojure の両方で小さなモジュールを作成したことがあります。Clojure プログラムには約 250 の loc があり、Groovy には 1000 の loc がありました。興味深いことに、ある複雑な関数を見て、同じような方法で書いてみると、まったく同じ行数でした。これは、Groovy コードがボイラープレートで埋め尽くされていることを示しており、Clojure を使い始める理由がいくつか追加されました :)

他の人が言ったように、コミットを見るときにも良いです。削除したよりも多くのコード行を導入した場合は、ソリューションの複雑さが増していることに注意する必要があります。問題自体が複雑さを増していない場合、これにより解決策を再考する必要があります。また、コード行をさらに追加する場合は、リファクタリングに時間を費やす必要があるというリファクタリングを促進するために、自分で作成することもお勧めです。

最後に、loc を減らすのに苦労して読みにくいものを書くこともできますが、ほとんどの場合、loc が少ないソリューションの方が読みやすくなります。

metrics - 「コードの行数」が有用な指標になるのはいつですか?

45 に答える 45

Related

Reference