ロケーションごとのバグの平均数は、異なるプログラミング言語で同じですか？
コード行ごとのバグ/欠陥の平均数は、さまざまなプログラミング言語で「一定」であると言われています。 Rubyの10 KLOCには、c ++の10 KLOCと同じ数のバグがあります。この引数は通常、表現言語の使用を促進するために使用されます（python/Rubyをc ++/Assemblyよりも考えます）。同じ機能を説明する行数は少なくなります。
この主張がどこから来たのか誰か知っていますか？高レベルの言語はバグの減少につながりますか？
直観に反して、1000行あたりのエラー数は、関係する特定の言語に関係なく、比較的一定しているようです。 Steve McConnell、作者Code Completeとソフトウェア推定：黒のアートの謎解きは、この領域について詳しく説明しています。
私はすぐに手元にあるコピーを持っていません-彼らは仕事で私の本棚に座っています-しかし、すぐにGoogleが関連する引用を見つけました：
業界平均：「提供されたコード1000行あたり約15〜50のエラー」
（Steve）はさらに、これは通常、その背後にあるレベルの構造化プログラミングがあるコードの代表であると述べていますが、おそらくコーディング手法の混合が含まれています。
Code Completeから引用、ここにあります： http://mayerdan.com/Ruby/2012/11/11/bugs-per- line-of-code-ratio /
メモリが正しく機能している場合、スティーブはこれについて徹底的に議論し、数字が言語（C、C++、Java、アセンブリなど）で一定であり、困難（「コード行」の意味を定義するなど）があってもそれを示します。
最も重要なことに、彼は出典について多くの引用をしています-彼は根拠のない意見を提供していませんが、それらを裏付けるための参照があります。
これは煮詰められるようです。klocあたりの平均欠陥数は、特定の言語またはプラットフォームの固有の利点または欠点よりも、開発者が人間であるという事実の特性のようです。
（余談ですが、まだコードコンプリートをお持ちでない場合は、自分で購入して完全に読んでください。投資する価値があります。）
更新：ここでの答えのいくつかには、別の要因が関係しています-大規模な統計は、一般的な予測を行うのに役立ちますが、特定の予測を行うのには役立ちません。人口死亡率の表は、今年の交通事故で死亡する人の数を予測できますが、どの人が死亡するかはわかりません。同様に、klocあたりの欠陥数が比較的一定であることを示す業界統計を使用して、特定の開発者が実行するパフォーマンスや特定のプロジェクトで何が発生するかを予測することはできません。
主張は-せいぜい-素朴です。
SLOCは、おそらく2つ以上のプロジェクトのサイズを比較することを除いて、有用なものの正確な信頼できる指標ではありません。さらに、SLOCには物理的LOCと論理的LOCの2つの異なるタイプがあり、それらmightは大きく異なります。この例を考えてみましょう Wikipediaから ：
for (i = 0; i < 100; i += 1) printf("hello");
ここには1つの物理的なLOCがありますが、2つの論理的なLOC（forおよびprintfステートメント）があります。もちろん、例を次のように書くこともできます。
for (i = 0; i < 100; i += 1)
printf("hello");
これにより、2つの物理LOCと2つの論理LOCが得られます。物理的なLOCに依存する「ロケーションごとのバグ」測定は、プログラミングスタイルによって汚染されることは明らかであるため、測定はほとんど役に立たないでしょう。
一方、論理LOCを使用した場合、測定値は言語の構文の特異性に大きく依存します。結果のメトリックmightは、同じ言語で記述されたプロジェクトを比較する場合に少し役立ちますが、異なる言語で記述されたプロジェクトではかなり役に立ちません。
主張の考えられる原因の1つは、Les Hattonの Software failures-follies and fallacies です。
プログラミング言語の選択は、せいぜい信頼性とはあまり関係がないと結論付けることができます。
後で、このペーパーでは、CおよびC++の同様の欠陥密度について言及しています。
1つはCで、もう1つはオブジェクト設計のC++で、同じサイズの2つの同様のシステム（それぞれ約50,000行）を比較した最近の研究では、結果として生じる欠陥密度は、それぞれ1000行あたり2.4と2.9でほぼ同じであることが示されました。
ただし、これは、 "LOCあたりのバグ"がプログラミング言語全体で一定であること、またはそうであったとしても重要であることを意味するものではありません。
この観察は非常に古く、非常に由緒ある情報源、つまり本「The Mythical Man Month」のフレッド・ブルックスに由来しています。彼はIBMのトップマネージャーであり、何百万ものオペレーティングシステムOS/360を含む多くのプログラミングプロジェクトを管理していました。実際、彼はプログラムのバグの数はコードの長さに比例しないが、二次！彼の研究によると、バグの数はプログラムの長さの1.5乗に比例していました。つまり、10倍長いプログラムには30倍のバグがあります。そして彼はこれがすべてのプログラミング言語とプログラミング言語のレベルに及んだことを報告しました。
特定の言語について、LOCあたりのバグが一定であるとは思いません。 LOCあたりのバグは、一部のマネージャーがレビュー時間に関して開発者の品質を判断するために使用するメトリックのように見えます。
現在、その外では、一部の言語は他の言語よりもエラーや欠陥が発生しやすくなっています。通常、ただし常にではありませんが、これは高レベルの言語よりも低レベルの言語です。たとえば、CとC＃（またはJava）でのコーディングの例を挙げます。通常、それが現実であり、あなたが探している答えの核心が開発者の品質と適切なコーディングプラクティスにかかっているためです。私は、平均的なJava/C＃開発者よりもはるかに高いコード品質と低い欠陥数を持つ非常に優れたC開発者を見てきました。これは、シニア開発者とジュニア開発者を分ける1つの項目です。特定の時間枠で書き込むLOCの数ではなく、言語、LOC、または時間枠に関係なく、書き込みのコードの品質。
私が言える唯一の答えは、LOCが多いほど、欠陥が存在する可能性が高くなり、存在する欠陥が増えるということです。
コードの行ごとのバグ
バグ/ LOCは個人にのみ関連しています。ソースコードリポジトリとリンクするバグ追跡ツールを実装する企業向け。マネージャーは、過去の問題とコード変更によってソートされた開発者ごとに問題を整理することができます。
バグはあなたの仕事に関係しています
高度な経験、高度なスキル、非常にスマートで独立した仕事を引き受けることができる上級ソフトウェア開発者は、追跡システムに記録されるバグの方がはるかに多く、経験の浅いジュニア開発者よりはるかに多くの可能性があります。
それはどのようにして可能ですか？
上級開発者は、リスクの高い開発タスクに従事していることがよくあります。例として、コードのリファクタリングと新しいシステムの構築。ジュニア開発者は、シニア開発者の時間に値しない既知の問題を修正するために割り当てられることがよくあります。
したがって、タスク割り当てによって、ジュニアはバグを導入するのではなく、バグを修正します。上級開発者は、バグを導入するリスクを許されます。アーカイブしようとしているものの利点は、それらを完了するために発生する小さな問題よりも重要であるためです。タスク。
言語構文は重要です
言語がより少ないコード行でより多くを達成できるので、言語がより少ないバグを導入するという主張は完全な神話です。 C++/C＃/ Javaのような高度に構造化された言語では、Python/PHPのような言語は非常に構造化されていないため、開発者は目的の命令がどうあるべきかを書面で明確に表現する必要があります。これらの言語では、開発者を混乱させるだけでなく、言語パーサーも混乱させる記述式が可能です。
コンパイラはバグを減らします
何かが間違っていることを開発者に警告するコンパイラがなかったため、Python/PHPのバグがいくつプロダクションサーバーに侵入したか。 LOCあたりのバグを測定する場合、コンパイラがソースコードを処理する前または後のバグですか。
アップデート2019：
コンパイラーは、バグの性質や数に違いはありません。バグは純粋にソースコードを書いた人に関連しており、バグ自体は本質的に非常に主観的である可能性があります。
FWIW、私の経験では
バグには2種類あります。a）プログラムが期待に応えない場合と、b）プログラムがクラッシュ/ハング/コンパイルしないためにプログラムが妥当な期待に応えられない場合です。
言語に関係なく、タイプ（b）のバグはデータ/クラス構造の冗長性が原因で発生します。データ構造の一部で何かを変更すると、他の部分で1つ以上の対応する変更が行われるまで、構造が不整合/壊れた状態になります。 。これに寄与するのは、ソースコードの冗長性です。1行のコードを編集すると、他の部分で1つ以上の変更が行われるまで、コードが正しくなくなります。もちろん、これら2つのタイプの冗長性は密接に関連しており、プログラマーは超人ではないため、気が散ったり、物事を忘れたり、間違いを犯したりして、バグを発生させます。
これらのこと（繰り返しますが、私の経験では）は、実際には言語の機能ではなく、プログラマーのスキル/成熟度の機能です。バグが発生しにくいプログラムは、特定の機能セットについて、LOCの点ではるかに小さくなる傾向があります。
一部の人がプログラムを作成し、他の人がディレクトリを作成するシステムを見たことがあります。前者は後者に比べて「機能する」傾向があります。
コーディングエラーの重要な要素は、特定の種類のソリューション定義とそれを解決するためのコードとの間の「セマンティックギャップ」と呼ばれるものに関連していると期待します。さまざまなエラーが予想されます。特定の言語のパラダイムは特定の問題ドメインに密接に一致します。スプレッドシートは日常のビジネス計算に非常に適しているため、「コード」と「コード」の両方が問題ドメインに非常に近くなります。予想されるコードは、非常に簡潔（少しKLOC）であり、エラーもほとんどありません。逆に、アセンブラを使用すると、多くのKLOCが必要になり、膨大な数のエラーが発生する可能性があります。
実際には役に立たない指標であるコード行について話すのではなく、質問のこの部分に対処したいと思います。
高レベルの言語はバグの減少につながりますか？
これはバグ/ LOCとは異なります。これは、高レベルの言語が少ないコードでより多くのことを行えるためです。一部の機能要件の実装には、500行のLISPと15000行のx86アセンブリが必要になる場合があります。
そのため、すべての言語間でバグ/ LOCが一定であっても、上位レベルの言語ではバグの発生が少なくなります。