locごとのバグの平均数は、異なるプログラミング言語で同じですか？[閉まっている]

コード行ごとのバグ/欠陥の平均数は、さまざまなプログラミング言語で「一定」であると言われています。Rubyの10 KLOCには、c ++の10 KLOCと同じ数のバグがあります。同じ機能を記述する行の数が少なくなるため、引数は通常、表現力のある言語の使用を促進するために使用されます（python / ruby​​ over c ++ / assemblyなど）。

誰がこの主張がどこから来たのか知っていますか？高レベルの言語はバグの減少につながりますか？

直感に反して、1000行あたりのエラーの数は比較的一定であるようであり、関連する特定の言語を警戒しています。Code CompleteおよびSoftware Evaluation：Demystifying the Black Artの著者であるSteve McConnellが、この分野について詳しく説明しています。

コピーをすぐに手元に持っていない-仕事中に本棚に座っている-すぐにGoogleが関連する引用を見つけた：

業界平均：「配信されたコード1000行あたり約15-50エラー」。
（Steve）はさらに、これは通常、ある程度の構造化プログラミングが背後にあるコードを代表するものであるが、おそらくコーディングテクニックが混在していると述べています。

ここにあるCode Completeから引用：http : //mayerdan.com/ruby/2012/11/11/bugs-per-line-of-code-ratio/

メモリが正常に機能する場合、スティーブはこれについて徹底的な議論を行い、数字は言語（C、C ++、Java、アセンブリなど）で一定であり、困難（「コード行」の意味を定義するなど）にもかかわらず一定であることを示します。

最も重要なことには、彼は彼の情報源に対して多くの引用を持っています-根拠のない意見を提供していませんが、それらをバックアップするための参照を持っています。

要約すると、klocあたりの平均欠陥数は、特定の言語やプラットフォームの特有の長所や短所というよりも、開発者が間違いやすい人間であるという事実の特性のようです。

（余談：まだCode Completeをお持ちでない場合は、自分でコピーを購入して、よく読んでください。投資する価値は十分にあります。）

更新：ここでの答えのいくつかに関係する別の要因があります-大規模な統計は特定の予測ではなく一般的な予測を行うのに役立ちます。人口死亡率表では、今年の交通事故で何人が死亡するかを予測できますが、どの人が死亡するかはわかりません。同様に、klocごとに比較的一定の数の欠陥を示す業界統計を使用して、特定の開発者がどれだけうまくいくか、またはどれだけ悪くなるか、特定のプロジェクトで何が起こるかを予測することはできません。

申し立ては-せいぜい-素朴です。

SLOCは、2つ以上のプロジェクトのサイズを比較することを除いて、有用なものの正確な信頼できる指標ではありません。さらに、SLOCには物理LOCと論理LOCの2つの異なるタイプがあり、それらは大きく異なる場合があります。ウィキペディアのこの例を考えてみましょう。

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ごとのバグ」測定は、プログラミングスタイルによって汚染されることは明らかであるため、測定はほとんど役に立たないでしょう。

一方、論理LOCを使用した場合、測定は言語の構文の特異性に大きく依存します。同じ言語で書かれたプロジェクトを比較する場合、結果のメトリックは少し役立つかもしれませんが、異なる言語で書かれたプロジェクトにはかなり役に立ちません。

主張の可能性のある原因の1つは、Les Hattonのソフトウェアの失敗-愚かさと誤りです：

プログラミング言語の選択はせいぜい信頼性とは弱い関係にあると結論付けることができます。

後で、このペーパーではCおよびC ++の同様の欠陥密度に言及しています。

Cに1つ、オブジェクト設計のC ++に1つ、同様のサイズの2つの類似システム（それぞれ約50,000行）を比較する最近の研究では、結果の欠陥密度はそれぞれ1000行あたり2.4および2.9でほぼ同じであることが示されました。

ただし、これは、「LOCごとのバグ」がプログラミング言語間で一定であるという意味ではありません。

この観察結果は非常に古く、非常に由緒ある情報源、つまり彼の著書「The Mythical Man Month」のFred Brooksからのものです。彼は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、私の経験では

1. バグには次の2種類があります。a）プログラムが期待を満たしていない場合と、b）プログラムがクラッシュ/ハング/コンパイルしないために合理的な期待を満たせない場合。

2. 言語に関係なく、タイプ（b）のバグは、データ/クラス構造の冗長性が原因で発生します。データ構造の一部で何かを変更すると、他の部分で1つ以上の対応する変更が行われるまで、構造が不整合/破損状態になります。これに貢献するのはソースコードの冗長性です。コードの1行を編集すると、他の部分で1つ以上の変更が行われるまでコードが不正確になります。もちろん、これらの2種類の冗長性は密接に関連しています。プログラマーはスーパーパーソンではないため、気を散らし、物事を忘れ、間違いを犯し、それによってバグが発生します。

これらのこと（これも私の経験では）は実際には言語の機能ではなく、プログラマーのスキル/成熟度の機能です。バグが発生しにくいプログラムは、特定の機能セットに対して、LOCの観点からはるかに小さくなる傾向があります。

一部の人がプログラムを作成し、他の人がディレクトリを作成し、前者は後者と比較して「正常に動作する」傾向があるシステムを見てきました。

コーディングエラーの重要な要因は、特定のタイプのソリューション定義とそれを解決するコードとの「セマンティックギャップ」と呼ばれるものに関連すると考えられます。異なる、多くのエラーが予想されます。特定の言語のパラダイムは特定の問題領域と密接に一致します。スプレッドシートは日常のビジネス計算に非常に適しているため、問題の領域に非常に近い「コード」と「コード」の両方が生じます。予想されるコードは、非常に簡潔（小さなKLOC）であり、エラーもほとんどありません。逆に、アセンブラーを使用すると多くのKLOCが必要になり、膨大な数のエラーが発生する可能性があります。

実際には役に立たないコード行について話す代わりに、あなたの質問のこの部分に対処したいと思います。

高レベルの言語はバグの減少につながりますか？

これはバグ/ LOCとは異なります。高レベルの言語はより少ないコードでより多くのことを行うためです。一部の機能要件を実装するには、500行のLISPと15000行のx86アセンブリが必要になる場合があります。

そのため、バグ/ LOCがすべての言語間で一定であっても、高レベルの言語ではバグが少なくなります。