「コードの行数」が有用な指標となる場合はいつですか。
一部の人々は、コードの最大の敵はそのサイズであると主張し、私は同意する傾向があります。しかし、毎日あなたは次のようなことを聞き続けます
- 私は何とか一行のコードを書いています。
- 私はx行のコードを所有しています。
- Windowsは100万行のコードです。
質問：「#lines of code」が役立つのはいつですか？
ps：そのような発言がなされるとき、口調は「より多い方が良い」ことに注意してください。
削除コードを実行して、プロジェクトをより適切に実行できるようになると思います。
あなたが「X行の数」を削除したと言うことは印象的です。コードを追加するよりもはるかに便利です。
ダイクストラの有名な引用について誰も言及していないので、私は驚いています。
今日の私のポイントは、コードの行をカウントしたい場合、それらを「生成された行」ではなく「費やされた行」と見なすべきであるということです。元帳。
引用は「 本当にコンピューティング科学を教えることの残酷さについて 」という記事からのものです。
これはひどい指標ですが、他の人が指摘しているように、システムの全体的な複雑さの（非常に）大まかな考え方を提供します。 2つのプロジェクトAとBを比較していて、Aがコードの10,000行で、Bが20,000である場合、それはあまりわかりません-プロジェクトBが過度に冗長であるか、Aが超圧縮されている可能性があります。
一方、1つのプロジェクトが10,000行のコードで、もう1つのプロジェクトが1,000,000行の場合、一般に、2番目のプロジェクトは大幅に複雑になります。
この指標の問題は、プロジェクトへの生産性または貢献度の評価に使用されるときに発生します。プログラマー「X」がプログラマー「Y」として2倍の行数を書き込んだ場合、プログラマーはより多くの貢献をしているかもしれませんし、そうでないかもしれません-おそらく「Y」はより難しい問題に取り組んでいます...
友達に自慢するとき。
少なくとも、進歩のためではない：
「コードの行ごとにプログラミングの進行状況を測定することは、航空機の建造の進行状況を重量で測定することに似ています。」 - ビルゲイツ
ラインプリンターをロードするときに便利です。これにより、印刷しようとしているコードリストが消費するページ数がわかります。 ;）
私がそれが非常に貴重だと思うとき、一つの特別なケースがあります。あなたがインタビューに参加していて、彼らはあなたの仕事の一部は既存のC++/Perl/Java/etcを維持することになるとあなたに言ったとき。レガシープロジェクト。レガシープロジェクトに関与しているKLOC（およそ）の数をインタビュアーに尋ねると、彼らの仕事が必要かどうかについて、より良いアイデアが得られます。
ほとんどの指標と同様に、コンテキストがなければほとんど意味がありません。つまり、簡単な答えは次のとおりです。決してありません（ラインプリンターを除いて、それはおかしいです。最近、だれがプログラムを印刷するのですか？）
例：
あなたがレガシーコードのユニットテストとリファクタリングをしていると想像してください。最初は、50,000行のコード（50 KLOC）と1,000個のバグ（ユニットテストの失敗）から始まります。比率は1K/50KLOC = 50行のコードあたり1バグです。明らかにこれはひどいコードです！
数回後の反復で、例示的なリファクタリングによってknownバグを半分（および未知のバグはそれよりも多い可能性が高い）およびコードベースを5分の1に減らしました。比率は500/10000 = 20行のコードあたり1バグになりました。これは明らかにさらに悪いです！
あなたが作りたい印象に応じて、これは以下の1つ以上として提示できます。
- バグを50％削減
- コードが5分の1
- コードを80％削減
- バグとコードの比率が60％悪化
これらはすべて真であり（計算を間違えていなかったと仮定します）、これらすべてがsuckであり、このようなリファクタリングの取り組みが達成したはずの大幅な改善を要約しています。
約25年前に読んだ引用を言い換えると、
「メトリックとしてコード行を使用することの問題は、それがproblem "の複雑さではなく、solutionの複雑さを測定することです。
Journal of the ACMの記事で、David Parnasからの引用だと思います。
これを思い出します：
現在の手紙は、私がそれを短くする余地がなかったという理由だけで、非常に長いものです。
-ブレーズパスカル。
回答：否定的なコード行について話すことができるとき。のように：「私は今日、40の余分なコード行を削除しましたが、プログラムは以前と同様に機能しています。」
多くの異なる Software Metrics があります。コード行は最も使用されており、理解するのが最も簡単です。
コード行のメトリックが他のメトリックと相関する頻度に驚いています。コードのにおいを発見するために循環的複雑度を計算できるツールを購入する代わりに、私は多くの行を持つメソッドを探すだけですが、それらも複雑度が高い傾向があります。
コード行の使用の良い例は、メトリック：コード行あたりのバグです。それはあなたがあなたのプロジェクトで発見することを期待する必要があるバグの数の直感を与えることができます。私の組織では通常、コード1000行あたり約20のバグがあります。これは、10万行のコードを含む製品を出荷する準備ができており、バグデータベースに50のバグが見つかったことが示されている場合、さらにテストを行う必要があることを意味します。 1000行のコードごとに20個のバグがある場合、おそらく通常の品質に近づいています。
悪い使用例は、開発者の生産性を測定することです。コードの行ごとに開発者の生産性を測定すると、人々はより多くの行を使用してより少ない成果を達成する傾向があります。
プロジェクトのコードの合計行数を取ることは、複雑さを測定する1つの方法であることに同意します。
確かに、それが複雑さの唯一の尺度ではありません。たとえば、100行の難読化されたPerlスクリプトをデバッグすることは、5,000行をデバッグすることとは大きく異なりますJavaコメントテンプレートを使用したプロジェクト。
しかし、ソースを確認しないと、通常、10 MBのソースtarballは15 kbのソースtarballよりも複雑であると考えるかもしれませんが、コードの行数はより複雑であると考えるでしょう。
それは多くの点で役立ちます。
正確な番号は覚えていませんが、Microsoftには、平均してy行のバグがあるというコードのX行ごとに話しているWebキャストがありました。このステートメントを使用して、いくつかの基準を与えることができます。
- コードレビューアがどれだけうまく仕事をしているか。
- 複数のプロジェクトのバグ率を比較して、2人の従業員のスキルレベルを判断します。
私たちが見ているもう1つのことは、なぜそれほど多くの行があるのかということです。多くの場合、新しいプログラマーが込み合ってしまうと、関数を作成してカプセル化する代わりに、コードのチャンクをコピーして貼り付けるだけです。
私が1日にx行のコードを書いたのは恐ろしいことだと思います。問題の難易度、言語の記述などは考慮されていません。
特定のプロジェクトの頭上から参照できるコードの行数には有限の制限があるように思えます。制限は、おそらく平均的なプログラマーと非常に似ています。したがって、プロジェクトに200万行のコードがあることがわかっていて、プログラマが、バグがよく知っている5K行のコードに関連しているかどうかを理解できると期待できる場合は、400人を雇う必要があることがわかります。あなたのコードベースのためのプログラマーは誰かの記憶から十分にカバーされます。
これはまた、コードベースの成長を早すぎることについて2度考えさせ、それをより理解しやすくするためにそれをリファクタリングすることを考えさせるかもしれません。
私がこれらの数を作ったことに注意してください。
コード行は、コードファイルが大きくなりすぎているかどうかを知るのに役立ちます。うーん...このファイルは現在5000行のコードです。多分私はこれをリファクタリングする必要があります。
これは生産性と複雑さの指標です。すべてのメトリックと同様に、慎重に評価する必要があります。通常、単一の指標では完全な回答を得るには不十分です。
IE、500行のプログラムは5000行ほど複雑ではありません。次に、プログラムをよりよく理解するために他の質問をする必要がありますが、今ではメトリックがあります。
人を怖がらせたり印象づけたりするのに最適な指標です。それはそれについてであり、間違いなく、これら3つの例すべてで私が見ているコンテキストです。
Lines of Code（LoC）を数えることの長所と短所を詳しく説明する2つのブログ投稿を書きました。
コード行数（LOC）をどのようにカウントしますか？ ：アイデアは、物理的なカウントではなく、論理的なコード行数をカウントする必要があることを説明することです。これを行うには、たとえば NDepend などのツールを使用できます。
コード行数（LOC）を数えることがなぜ役立つのですか？ ：アイデアは、LoCを生産性の測定に使用すべきではなく、テストカバレッジ推定とソフトウェア期限の見積もり。
あなたが注文する必要があるパンチカードの数の予算を立てる必要があるとき。
ソフトウェアエンジニアリングインスティテュートのソフトウェアコミュニティのプロセス成熟度プロファイル：1998年末の更新（残念ながら、リンクが見つかりませんでした）は、約800のソフトウェア開発チーム（またはおそらくショップ）の調査について説明しています。平均欠陥密度は、1000 LOCあたり12欠陥でした。
欠陥のないアプリケーションがあり（実際には存在しないが、仮に考えてみましょう）、平均で1000のLOCを書き込んだ場合、システムに12の欠陥が導入されたと想定できます。 QAが1つまたは2つの欠陥を検出し、それだけの場合、おそらく10以上の欠陥があるため、彼らはより多くのテストを行う必要があります。
それが欠陥の数と関連しているとき、それは非常に有用な考えです。 「欠陥」はあなたにコード品質の尺度を与えます。最小限の「欠陥」でソフトウェアが良くなります。すべての欠陥を取り除くことはほとんど不可能です。多くの場合、単一の欠陥は有害で致命的となる可能性があります。
ただし、正常なソフトウェアが存在するようには見えません。
コードベースをリファクタリングしていて、コードの削除済み行であることを示すことができ、すべての回帰テストがまだ成功している場合。
ウィキペディアの定義を確認してください： http://en.wikipedia.org/wiki/Source_lines_of_code
SLOC = 'コードのソース行'
実際、私が作業するこれらの指標にはかなりの時間が費やされています。 SLOCをカウントする方法もいくつかあります。
ウィキペディアの記事から：
SLOCメジャーには、物理SLOCと論理SLOCの2つの主要なタイプがあります。
別の優れたリソース： http://www.dwheeler.com/sloc/
コードの行はそれほど有用ではなく、管理者がメトリックとして使用すると、プログラマーがスコアを上げるために多くのリファクタリングを行うことになります。さらに、貧弱なアルゴリズムがきちんとした短いアルゴリズムに置き換わることはありません。LOCカウントがマイナスになり、不利になるからです。正直に言うと、LOC/dを生産性の指標として使用している会社で働いてはいけません。経営陣は明らかにソフトウェア開発について何の手がかりも持っていないので、初日からいつも後を追うことになります。
変更が非常に長くかかる理由を指摘するとき。
「Windowsは700万行のコードであり、すべての依存関係をテストするには時間がかかります...」
大会で。
コーダーがあなたがコードの行を数えていることを知らないので、故意に冗長なコードをシステムに追加する理由はありません。そして、チームの全員が同じようなコーディングスタイルを持っている場合（したがって、行ごとに既知の平均 "値"があります。）そして、より良い測定値がない場合に限ります。
作業レベル（LOE）を決定するとき。提案をまとめて、ほぼ同じエンジニアが新しいプロジェクトに取り組んでいる場合、どれだけの数のエンジニアがどれだけの期間必要かを判断できる可能性があります。
ほとんどの人がすでに述べたように、特に異なる言語でコーディングしている人を比較している場合は、あいまいなメトリックになる可能性があります。
LISPの5,000行！= Cの5,000行
私はそれが2つの条件の下で役に立つとわかりました：
コーディング時間を短縮する際に、自分の新しいプロジェクトで自分の生産性を測定する。
大企業と仕事をしていて、1日あたりのウィジェットしか理解していないマネージャーと話すとき。
まず、生成されたコードを除外し、ジェネレーターの入力とジェネレーター自体のコードを追加します。
次に、（皮肉なことに）コードのすべての行にバグが含まれている可能性があり、維持する必要があると言います。より多くのコードを維持するには、より多くの開発者が必要です。その意味で、より多くのコードはより多くの雇用を生み出します。
上記のステートメントから単体テストを除外したいのは、単体テストを少なくしても、一般に保守性が向上しないためです。
マイクロソフトは6か月ごとに5％の人を解雇していたと聞きましたが、これは記述されたコード行に基づくものだと常に想像していました。そのため、Windowsは非常に大きく、遅く、非効率です。コードの行は、アプリケーションの複雑さを大まかな順序で測定するのに役立つメトリックです。つまり、Basicの初心者プログラムは10行のコード、100行のコードはおもちゃのアプリケーション、50000行は妥当なサイズのアプリケーション、10 100万行のコードは、Windowsと呼ばれる怪物です。
コードの行はあまり有用な指標ではありませんが、私はアセンブリ言語（主に68000）でゲームを作成していましたが、約5万行のコードで測定していましたが、レジスターをスタックとレジスタに含まれているものを追跡してコードサイズを削減します（私が知っていた他のプログラマは、d0-d7、a0-a6の倍数をスタックにプッシュしました。これにより、明らかにコードが遅くなりますが、追跡を簡単に影響を受けるもの）。
前述の「自慢」の目的は別として、機能的には決してありません。
行！=効果。私の経験では、しばしば関係は逆になります（明確な理由のために、特に極端ではないが）
リスク評価の目的では、これは複雑さの非常に優れた指標になる可能性があります。変更された行が増えるほど、バグが発生する可能性が高くなります。
言語を比較するときに役立ちます。私はかつて、GroovyとClojureの両方で小さなモジュールを作成しました。 Clojureプログラムには約250の場所とGroovy 1000の場所がありました。興味深いことに、私が1つの複雑な関数を見て、同じようにそれを書いたとき、それはまったく同じ行数でした。これは、Groovyコードがボイラープレートでいっぱいになっていることを示すものであり、Clojureの使用を開始するいくつかの追加の理由を教えてくれました:)
他の人が言ったように、コミットを見るときにも良いです。削除したコードよりも多くのコード行を導入した場合は、ソリューションの複雑さが増していることに注意する必要があります。これにより、問題自体が複雑さを増さない場合は、ソリューションを再考する必要があります。また、リファクタリングを奨励するために自分で作って、コードの行を追加する場合は、リファクタリングに時間をかける必要があります。
最後に、locを小さくしすぎて読みにくいものを書くこともできますが、locが少ないソリューションの方が、読み取りが少ないため、ほとんどの場合読みやすくなります。
コード行は、異なるプロジェクトを比較するための有用な指標ではありません。
ただし、コードベースのサイズが時間の経過とともにどのように変化するかを監視するために、プロジェクト内で動く図として役立ちます。各ビルドでコードの行を示すCIプロセスの一部としてグラフを生成すると、プロジェクトがどのように進化しているかを視覚化するのに役立ちます。
この文脈でも、正確な「コード行」の数値自体は重要ではないと私は主張します。便利なのはトレンドの視覚化です-より多くの機能が追加されるにつれて着実に上昇します。大きなプロジェクトが完了するジャンプ。冗長なコードが少し削除されたディップ。
これは、セールスプレゼンテーションで頻繁に使用されます。たとえば、KLoC（Kilo Lines of Code）またはLoCは、ベンダー組織が大規模/複雑なシステムに対して持つ能力の種類を示すために使用されます。これは、ベンダーが複雑なレガシーシステムを維持する能力を紹介しようとしている場合に特に当てはまります。交渉の一環として、顧客組織がベンダーと一緒にProof of Conceptを実行してベンダーの機能をテストするための代表的なコードを提供することがあります。この代表的なコードは、ベンダー企業が処理するのに十分な複雑さと、数百万のLoCを備えたシステム」がレーダーの対象になる可能性があります。
そのため、はい。コードの行は、販売プレゼンテーション中に使用および悪用されるため、販売において有用な指標となります。
コードの行は言語に依存しています。
たとえば、Cコードの1行は、ASMコードの平均x行に相当します。 C++の1行-> Cなど...
JavaとC＃は、VMからのバックグラウンドサポートにより、コードのかなりの行をカプセル化します。
特定のタスクに追加されるコードの数は、コードを書いている人によって大きく異なります。生産性の指標として使用しないでください。特定の個人が1000行の冗長で複雑ながらくたを生成することができ、同じ問題が別の個人によって10行の簡潔なコードで解決される可能性があります。指標として追加されたLOCを使用する場合は、「誰」の要素も考慮する必要があります。
実際に役立つメトリックは、「追加された行数に対して検出された欠陥の数」です。これにより、特定のチームまたは個人のコーディングおよびテストカバレッジ機能がわかります。
他の人も指摘したように、削除されたLOCは追加されたLOCよりも自慢できる権利があります:)
これは主に、すでにボリュームのある解説への追加です。しかし、基本的に、コードの行（またはおそらくtotalCharacterCount/60）はモンスターのサイズを示します。少数の人々が言ったように、それはコードベースの複雑さの手がかりを与えます。複雑さのレベルは大きな影響を与えます。部分的には、システムを理解して変更を加えることがいかに難しいかに影響を与えます。
これが、人々がより少ないコード行を望んでいる理由です。理論的には、コードの行が少ないほど複雑さが少なくなり、エラーの余地が少なくなります。 upfrontを知ることが、見積もりや計画以外のすべての場合に非常に役立つことはわかりません。
例：プロジェクトがあるとしますが、ざっと調べたところ、10,000行あるアプリケーション内の1000行ものコードを変更することが関係していることがわかりました。このプロジェクトは実装に時間がかかり、安定性が低く、デバッグとテストに時間がかかる可能性があることを知っています。
また、2つのビルド間の変更の範囲を理解するのにも非常に役立ちます。 2つのSVNリビジョン間の変更の範囲を分析する小さなプログラムを作成しました。統一された差分を調べ、そこから、追加、削除、または変更された行の数を把握します。これは、新しいビルドに続くテストとQAで何を期待するかを知るのに役立ちます。基本的に、変更の数が多いほど、そのビルドを注意深く観察し、完全なリグレッションテストを実施するなどする必要があります。
コード行数は、コード行が製品サイズの一般的な指標であると考える顧客に包括的な製品の広さを売り込むときに役立ちます。たとえば、製品が多くのコーナーケースを処理するように説得しようとしている場合や、ツールベンダーがテスト目的で最大限のコードカバレッジを取得したいと考えている開発ツールのベータ版を取得しようとしている場合です。
LOCの数は、不良率（1,000 LOCあたりのバグなど）を計算するときに役立ちます。
それらはアプリケーションの大きさを示すのに役立ちます-品質については何も言いません！ここでの私のポイントは、1,000行のアプリケーションで作業していて、そのアプリケーションが（およそ）500k行ある場合、潜在的な雇用主は、大規模なシステムの経験と小規模なユーティリティプログラミングのどちらを使用しているかを理解できるということです。
システムから削除するコードの行数は、追加する行数よりも有用であることをwarrenと完全に同意します。
常に。この質問についての新人をまとめます。マスターはコードを多作かつ密に記述します。良い卒業生はたくさんの線を書きますが、綿毛が多すぎます。クラッパーはコード行をコピーします。もちろん、最初にタイル分析またはゲートを行います。
LoCは、組織が複雑さのポイント、機能ポイント/関数ポイント、コミット、またはその他の分析を行わない場合に使用する必要があります。
LoCで彼または彼女を測定しないように指示する開発者は誰でもシテです。マスタークランクは、信じられないようなコードをコード化します。私は、平均的なプログラマーの20倍から200倍の生産性を持つ少数のユーザーと協力してきました。そして、彼らのコードは非常に、非常に、非常にコンパクトで効率的です。はい、ダイストラのように、彼らは巨大なメンタルモデルを持っています。
最後に、どんな事業でも、ほとんどの人はそれが得意ではなく、ほとんどの人はそれが上手ではありません。プログラミングも同じです。
はい、大規模なプロジェクトでヒット分析を行い、20％以上がデッドコードであることを確認します。繰り返しになりますが、マスタープログラマーは定期的にデッドコードとクラップコードを全滅させます。