有人告诉我,对于不同的编程语言,每行代码的错误/缺陷的平均数量是“恒定的”。Ruby的10 KLOC与c ++的10 KLOC具有相同数量的错误。该参数通常用于促进表达语言的使用(考虑python / ruby而不是c ++ / assembly),因为描述相同功能的行数会更少。
有人知道这种说法的来源吗?高级语言会导致更少的错误吗?
有人告诉我,对于不同的编程语言,每行代码的错误/缺陷的平均数量是“恒定的”。Ruby的10 KLOC与c ++的10 KLOC具有相同数量的错误。该参数通常用于促进表达语言的使用(考虑python / ruby而不是c ++ / assembly),因为描述相同功能的行数会更少。
有人知道这种说法的来源吗?高级语言会导致更少的错误吗?
Answers:
与直觉相反,每千行错误的数量确实相对恒定,无需考虑所涉及的特定语言。史蒂夫·麦康奈尔(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,请自己购买一份副本并仔细阅读它-值得投资。)
更新:这里的一些答案还有另一个因素在起作用-大规模统计数据对于进行一般性预测很有用,但对特定的预测却无济于事。考虑一下,人口死亡率表可以预测今年有多少人在交通事故中丧生,但无法告诉您哪些人会死。同样,行业统计数据显示每千公吨的缺陷数量相对恒定,因此不能用来预测特定开发人员的表现或特定项目的表现。
这种说法充其量是幼稚的。
对于可能有用的任何事物,SLOC并不是一个可靠的指标,除了可能比较两个或更多项目的规模。此外,还有两种不同的SLOC类型,即物理LOC和逻辑LOC,并且它们可能会显着不同。考虑这个例子,来自维基百科:
for (i = 0; i < 100; i += 1) printf("hello");
在这里,我们有一个物理LOC,但是有两个逻辑LOC(for
和printf
语句)。但是我们当然可以将示例编写为:
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的错误”在各种编程语言中都是恒定的,或者如果是这样的话,则意义重大。
对于给定的语言,我发现每个LOC的Bug都不是一个常数。每个LOC的错误似乎是一些管理人员用来确定开发人员质量的指标,用于评估时间。
除此之外,某些语言比其他语言更容易出现错误或缺陷。通常,但并非总是如此,这是一种比高级语言更底层的语言。例如,用C与C#(或Java)进行编码之所以如此,通常是因为它的真实性和所寻找答案的症结在于开发人员的素质和适当的编码实践。我见过非常优秀的C开发人员,它们的代码质量和缺陷计数比普通Java / C#开发人员高得多。这是将高级开发人员与初级开发人员区分开的一项。它们不是在给定的时间范围内写入多少LOC,而是无论语言,LOC或时间范围如何,代码的写入质量。
我唯一可以给出的答案可能是,LOC越多,出现缺陷的可能性就越大,存在的缺陷就越多。
错误/ LOC仅与个人有关。对于实施与它们的源代码存储库链接的错误跟踪工具的企业。经理可以按开发人员组织问题,并根据过去的问题和代码更改进行分类。
经验丰富,技能娴熟,非常聪明并且能够胜任独立工作的高级软件开发人员更有可能在跟踪系统中记录更多的错误,而相比之下,经验不足的初级开发人员则更有可能。
那怎么可能?
高级开发人员通常从事较高风险的开发任务。以代码重构和构建新系统为例。初级开发人员通常被分配来解决高级开发人员所不值得的已知问题。
因此,通过任务分配,初级人员不是在引入错误,而是在修复它们,而高级开发人员则有引入它们的风险,因为他们尝试归档的内容的好处比完成这些问题所引起的次要问题更为重要。任务。
一种语言引入较少错误的论点,因为它可以用更少的代码行实现更多的错误,这是一个完全的神话。像C ++ / C#/ Java这样的高度结构化的语言迫使开发人员在编写时清楚地表达所需指令的含义,而像Python / PHP这样的语言却是非常非结构化的。这些语言允许使用书面表达方式,这不仅会使开发人员感到困惑,而且还会使语言解析器感到困惑。
由于没有编译器警告开发人员某些错误,因此Python / PHP中有多少错误已将其引入生产服务器。当您按LOC衡量错误时,是在编译器处理源代码之前还是之后?
更新2019:
编译器对错误的性质或数量没有影响。错误纯粹是与编写源代码的人有关的,错误本身在本质上可以是非常主观的。
FWIW,以我的经验
有两种错误:a)程序未达到预期的期望,b)程序因崩溃/挂起/无法编译而无法达到任何合理的期望。
无论使用哪种语言,类型(b)的错误都是由数据/类结构中的冗余引起的,在这种情况下,更改数据结构一部分中的某些内容会使结构处于不一致/中断状态,直到在其他部分中进行一个或多个相应更改为止。造成这种情况的原因是源代码的冗余,其中对一行代码的编辑使该代码不正确,直到在其他部分进行了一个或多个更改为止。当然,这两种类型的冗余是紧密相关的,并且由于程序员不是超级人,所以他们会分神,忘却事情并犯错误,从而引发错误。
这些事情(再次以我的经验)并不是语言的功能,而是程序员的技能/成熟度。对于给定的功能集,就LOC而言,易于发生错误的程序也往往要小得多。
我见过一些系统,其中有些人编写程序,而另一些人编写目录,与前者相比,前者往往“工作正常”。
我希望编码错误中的一个关键因素与我所说的特定类型的解决方案定义和解决该问题的代码之间的“语义鸿沟”有关-在这些地方,紧密的重新设计错误会更加明显,而代码非常不同,可能会出现许多错误。某些语言的范例与某些问题领域紧密匹配-电子表格非常适合日常业务计算,从而导致很少的“代码”和“代码”都非常接近问题领域。预期的代码非常简洁(小KLOC)并且几乎没有错误。相反,使用汇编程序将需要许多KLOC,并且可能会产生大量错误。