不同编程语言的每个位置的平均错误数量是否相同?[关闭]


45

有人告诉我,对于不同的编程语言,每行代码的错误/缺陷的平均数量是“恒定的”。Ruby的10 KLOC与c ++的10 KLOC具有相同数量的错误。该参数通常用于促进表达语言的使用(考虑python / ruby​​而不是c ++ / assembly),因为描述相同功能的行数会更少。

有人知道这种说法的来源吗?高级语言会导致更少的错误吗?


11
考虑到某些语言鼓励一种将更多的语句打包成一行的样式,似乎比其他语言更合理。
Caleb

10
错误/ LOC是对所有事物的错误度量。它取决于语言,但更多地取决于程序员来编写它。因此,对语言取平均值是没有意义的,因为另一个变量会引起较大的波动。这只是IMO,ofc。
K.Steff

3
我可以告诉你,我在Perl中编写的错误/行的数量将比我在C中编写的数量大得多。我的一个朋友是Perl向导,对他而言,C中的错误/行比Perl。很难看到该指标可能如何有用。
Caleb


2
我只是遇到了这个问题。我不知道为什么关闭它。这是本网站的一个完美问题。对于大型项目,每个KLOC的错误不能衡量程序员的水平。它衡量组织和流程的良好程度。
大卫·哈曼

Answers:


43

与直觉相反,每千行错误的数量确实相对恒定,无需考虑所涉及的特定语言。史蒂夫·麦康奈尔Steve McConnell)是《代码完成软件估计:揭秘妖术》一书的作者。

我手头上没有我的副本-他们正坐在我的书架上工作-但是Google很快找到了一个相关的报价:

业界平均水平:“每千行交付的代码大约15至50个错误。”
(史蒂夫)进一步说,这通常代表代码,该代码后面具有一定程度的结构化编程,但可能包括多种编码技术。

引用自Code Complete的代码,可在此处找到:http : //mayerdan.com/ruby/2012/11/11/bugs-per-line-of-code-ratio/

如果内存能够正确工作,Steve将会对此进行深入的讨论,表明在各种语言(C,C ++,Java,Assembly等)中,图形是不变的,尽管存在困难(例如定义“代码行”的含义)。

最重要的是,他为自己的消息来源提供了很多引文-他没有提供没有根据的观点,但有引用来支持这些观点。

似乎可以归结为:每个kloc的平均缺陷数似乎更多是由于开发人员是易犯错误的事实,而不是特定语言或平台的特殊优点或缺点。

(此外:如果您还没有Code Complete,请自己购买一份副本并仔细阅读它-值得投资。)

更新:这里的一些答案还有另一个因素在起作用-大规模统计数据对于进行一般性预测很有用,但对特定的预测却无济于事。考虑一下,人口死亡率表可以预测今年有多少人在交通事故中丧生,但无法告诉您哪些人会死。同样,行业统计数据显示每千公吨的缺陷数量相对恒定,因此不能用来预测特定开发人员的表现或特定项目的表现。


4
没有软件评估的副本,但是在Code Complete中,McConnel引用Capers Jones的“程序质量和程序员生产力” 1977报告作为每个项目规模每个LOC的错误表的来源。McConnel试图指出的一点是,随着项目规模的增加,错误会急剧增加,并指出数据只是“行业的小偷”,而且“这些数字可能与您从事的项目几乎没有相似之处。 ”。我真的看不到任何与此问题有关的东西。
RocMartí13年

您拥有@RocMartí的哪个版本的Code Complete?我知道第二版是一个重大更新。星期一我上班时,必须把它弄清楚,看看它说什么。
2013年

我认为您的编辑(Update:)是问题的核心。或者,正如马克吐温所说的那样,存在三种谎言:谎言,该死的谎言和统计信息。
GalacticCowboy

1
@RocMartí“随着项目规模的增加,错误急剧增加”他是否还指出水是湿的?当事情变得更加复杂时,当然会有错误。因为每项新更改都必须牢记每一个可能受到影响的部分。随着项目的增长而增长。
Parthian Shot 2014年

3
报价错误或过时。在第二版中,它在第521页上:“行业平均经验是,所交付软件的每1000行代码约有1-25个错误。该软件通常是使用多种技术开发的。”
Aryeh Leib Taurog

18

这种说法充其量是幼稚的。

对于可能有用的任何事物,SLOC并不是一个可靠的指标,除了可能比较两个或更多项目的规模。此外,还有两种不同的SLOC类型,即物理LOC和逻辑LOC,并且它们可能会显着不同。考虑这个例子,来自维基百科

for (i = 0; i < 100; i += 1) printf("hello"); 

在这里,我们有一个物理LOC,但是有两个逻辑LOC(forprintf语句)。但是我们当然可以将示例编写为:

for (i = 0; i < 100; i += 1) 
  printf("hello"); 

这将给我们两个物理LOC和两个逻辑LOC。我认为很明显,任何依赖于物理LOC的“每位置错误”度量都将受到编程风格的污染,因此我们的度量在很大程度上将毫无用处。

另一方面,如果我们使用逻辑LOC,则我们的度量将在很大程度上取决于语言的句法特质。尽管在比较以相同语言编写的项目时,所得的度量标准可能会有些用,但对于以不同语言编写的项目而言,它却毫无用处。

索赔的一个可能来源是Les Hatton的软件故障-愚蠢和谬误

我们可以得出结论,编程语言的选择最多与可靠性无关。

稍后,本文提到了C和C ++的类似缺陷密度:

在最近的一项研究中,比较了两个类似大小的相似系统(每个大约50,000行),一个在C中,一个在对象设计的C ++中,结果表明缺陷密度大约相同,分别为每1000行2.4和2.9。

但是,这并不意味着“每种LOC的错误”在各种编程语言中都是恒定的,或者如果是这样的话,则意义重大。


如果您认为错误/陈述是不变的,那么语言就有所不同。C示例通常在for()和printf()参数中存在错误。如果您必须完全编写出printf功能的代码,那么您将有更多的错误,并且如果您使用单个printRepeat()进行高级语言调用,那么出错的机会就会更少。
马丁·贝克特

2
简介:每个语句/功能点的错误是恒定的,低级语言由易犯错误的程序员编写的代码更多,而您键入的高级语言则更少-因此错误也更少。尽管完全错误的设计类型错误可能是相同的!
马丁·贝克特

2
更不用说什么构成“一个错误”是高度主观的,并且这些错误在严重性,影响和重要性上有很大的不同。
tdammers

@tdammers而且这种重要性可能是消极的。我们有一些客户习惯/期望/想要的错误,因此我们无法修复……
Izkata

@Izkata:取决于您对错误的定义...
tdammers

12

这种观察是非常古老的,来自非常古老的来源,即弗雷德·布鲁克斯(Fred Brooks)在他的著作《神话中的男人月》中。他曾是IBM的高级经理,并管理过许多编程项目,包括数以百万计的操作系统OS / 360。实际上,他报告说程序中的错误数量与代码的长度不成比例,而是二次方!根据他的研究,错误的数量与程序的长度乘以1.5的幂成正比。换句话说,十倍长的程序有30倍以上的错误。他报告说,这适用于所有编程语言和编程语言级别。


6

对于给定的语言,我发现每个LOC的Bug都不是一个常数。每个LOC的错误似乎是一些管理人员用来确定开发人员质量的指标,用于评估时间。

除此之外,某些语言比其他语言更容易出现错误或缺陷。通常,但并非总是如此,这是一种比高级语言更底层的语言。例如,用C与C#(或Java)进行编码之所以如此,通常是因为它的真实性和所寻找答案的症结在于开发人员的素质和适当的编码实践。我见过非常优秀的C开发人员,它们的代码质量和缺陷计数比普通Java / C#开发人员高得多。这是将高级开发人员与初级开发人员区分开的一项。它们不是在给定的时间范围内写入多少LOC,而是无论语言,LOC或时间范围如何,代码的写入质量。

我唯一可以给出的答案可能是,LOC越多,出现缺陷的可能性就越大,存在的缺陷就越多。


我的问题是关于独立于语言的每行代码的平均缺陷数。
克里斯蒂安

4
@克里斯蒂安没有这个数字。相对于开发人员的工作和专业知识以及他们所使用的语言,每个人的情况都会发生变化。我认为没有一个普遍的平均值。
Akira71

1
@ Akira71“没有这样的数字”好吧,当然。但是存在概率分布,您可以从中提取数字。亚马逊雨林中每年有多少英寸的雨水也没有数字,但您可以取平均数。
Parthian Shot

3

每行代码的错误

错误/ LOC仅与个人有关。对于实施与它们的源代码存储库链接的错误跟踪工具的企业。经理可以按开发人员组织问题,并根据过去的问题和代码更改进行分类。

错误与您的工作有关

经验丰富,技能娴熟,非常聪明并且能够胜任独立工作的高级软件开发人员更有可能在跟踪系统中记录更多的错误,而相比之下,经验不足的初级开发人员则更有可能。

那怎么可能?

高级开发人员通常从事较高风险的开发任务。以代码重构和构建新系统为例。初级开发人员通常被分配来解决高级开发人员所不值得的已知问题。

因此,通过任务分配,初级人员不是在引入错误,而是在修复它们,而高级开发人员则有引入它们的风险,因为他们尝试归档的内容的好处比完成这些问题所引起的次要问题更为重要。任务。

语言语法很重要

一种语言引入较少错误的论点,因为它可以用更少的代码行实现更多的错误,这是一个完全的神话。像C ++ / C#/ Java这样的高度结构化的语言迫使开发人员在编写时清楚地表达所需指令的含义,而像Python / PHP这样的语言却是非常非结构化的。这些语言允许使用书面表达方式,这不仅会使开发人员感到困惑,而且还会使语言解析器感到困惑。

编译器减少错误

由于没有编译器警告开发人员某些错误,因此Python / PHP中有多少错误已将其引入生产服务器。当您按LOC衡量错误时,是在编译器处理源代码之前还是之后?

更新2019:

编译器对错误的性质或数量没有影响。错误纯粹是与编写源代码的人有关的,错误本身在本质上可以是非常主观的。


3
重新减少编译器的错误:Python和PHP在技术上都拥有编译器,它们只是不执行与静态类型的语言相同的检查。我也不同意这种检查对结束错误计数有重大影响,因为实际上编译器可以捕获的所有错误都是通过最少的测试即可捕获的。
Winston Ewert

3
同意编译器可能捕获的错误通常会通过合理的自动化或手动测试来捕获。区别在于,静态类型的语言使您(a)免费进行测试,并且(b)确实非常迅速地进行了第一轮测试。一个好的Ruby单元测试套件比编译器要好,但是您通常无法以如此快的速度运行它们,也无法免费获得它们,而且它们通常不会与代码行紧近地指向。问题。
肯·史密斯

@KenSmith静态类型不是免费的。courses.cs.washington.edu/courses/cse590n/10au/...
雨果伍德

1

FWIW,以我的经验

  1. 有两种错误:a)程序未达到预期的期望,b)程序因崩溃/挂起/无法编译而无法达到任何合理的期望。

  2. 无论使用哪种语言,类型(b)的错误都是由数据/类结构中的冗余引起的,在这种情况下,更改数据结构一部分中的某些内容会使结构处于不一致/中断状态,直到在其他部分中进行一个或多个相应更改为止。造成这种情况的原因是源代码的冗余,其中对一行代码的编辑使该代码不正确,直到在其他部分进行了一个或多个更改为止。当然,这两种类型的冗余是紧密相关的,并且由于程序员不是超级人,所以他们会分神,忘却事情并犯错误,从而引发错误。

这些事情(再次以我的经验)并不是语言的功能,而是程序员的技能/成熟度。对于给定的功能集,就LOC而言,易于发生错误的程序也往往要小得多。

我见过一些系统,其中有些人编写程序,而另一些人编写目录,与前者相比,前者往往“工作正常”。


1

我希望编码错误中的一个关键因素与我所说的特定类型的解决方案定义和解决该问题的代码之间的“语义鸿沟”有关-在这些地方,紧密的重新设计错误会更加明显,而代码非常不同,可能会出现许多错误。某些语言的范例与某些问题领域紧密匹配-电子表格非常适合日常业务计算,从而导致很少的“代码”和“代码”都非常接近问题领域。预期的代码非常简洁(小KLOC)并且几乎没有错误。相反,使用汇编程序将需要许多KLOC,并且可能会产生大量错误。


这是如何被否决的?SO到处都是小丑
codyc4321

0

与其谈论代码行(的确是无用的指标),我想解决您的问题的这一部分:

高级语言会导致更少的错误吗?

这与bug / LOC不同,因为高级语言用更少的代码就能做更多的事情。实现某些功能要求可能需要500行LISP与15000行x86组装。

因此,即使所有语言之间的bug / LOC不变,高级语言仍会产生较少的bug。


2
代码行是“无用的度量”吗?不,这是程序复杂度的粗略估计。它非常有用,因为它易于测量,并且与开发时间密切相关。
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.