什么时候，如果“代码行数”是一个有用的指标？

Question

有些人声称代码最大的敌人是它的大小，我倾向于同意。然而，每天你都会听到像

这样的事情

• 我在一天内写下代码行。
• 我拥有x行代码。
• Windows是x百万行代码。

问题：“＃lines of code”何时有用？

ps：请注意，在做出这样的陈述时，语气“越多越好”。

Answer 1

我会说，当你删除代码以使项目运行得更好时。

说你删除了“X行数”令人印象深刻。而且比你添加的代码行更有帮助。

Answer 2

我很惊讶没有人提到Dijkstra的名言，所以这里有：

  

我今天的观点是，如果我们希望计算代码行数，我们不应该将它们视为“产生的线条”，而应视为“花费的线条”：当前的传统智慧是如此愚蠢以至于指出错误分类帐的一面。

引用来自一篇名为“On the cruelty of really teaching computing science”的文章。

Answer 3

这是一个糟糕的指标，但正如其他人所指出的那样，它可以让您（非常）粗略地了解系统的整体复杂性。如果您要比较两个项目，A和B，A是10,000行代码，B是20,000，这并没有告诉你太多 - 项目B可能过于冗长，或者A可能被超级压缩。

另一方面，如果一个项目是10,000行代码，另一个项目是1,000,000行，那么第二个项目通常要复杂得多。

当该指标用于评估某个项目的生产率或贡献水平时，会出现此问题的问题。如果程序员“X”将行数写为程序员“Y”的2倍，他可能会或可能不会贡献更多 - 也许“Y”正在处理更难的问题...

Answer 4

向朋友吹牛时。

Answer 5

至少，不是为了进步：

  

“按行代码测量编程进度就像按重量衡量飞机制造进度一样。” - 比尔盖茨

Answer 6

在加载行式打印机时非常有用，这样您就可以知道您要打印的代码将消耗多少页面。 ;）

Answer 7

当我发现它非常有价值时，有一个特例。当你在面试时他们告诉你，你的部分工作将是维护现有的C ++ / Perl / Java /等。遗产项目。向面试官询问遗留项目涉及多少KLOC（大约）将让您更好地了解您是否想要他们的工作。

Answer 8

像大多数指标一样，如果没有上下文，它们意味着很少。所以简短的回答是：从来没有（除了行式打印机，这很有趣！这些天谁打印出程序？）

一个例子：

想象一下，您正在对遗留代码进行单元测试和重构。它开始时有50,000行代码（50 KLOC）和1,000个可证明的错误（单元测试失败）。该比率为1K / 50KLOC =每50行代码1个错误。显然这是可怕的代码！

现在，经过几次迭代，你已经将已知的错误减少了一半（并且未知的错误超过最可能的错误），并且通过示例性重构将代码库减少了五倍。该比率现在为每20行代码500/10000 = 1个错误。这显然更糟糕！

根据您要制作的展示次数，可以将其显示为以下一项或多项：

• 减少50％的错误
• 少了五倍的代码
• 减少80％的代码
• 错误与代码比率恶化60％

所有这些都是正确的（假设我没有搞砸数学），并且他们都 suck 总结了这种重构努力必须实现的巨大改进。

Answer 9

让我想起这个：

  

这封信很长，只是因为我没有闲暇让它缩短。   
--Blaise Pascal。

Answer 10

用25年前我读过的一句话来解释，

＆＃34;使用代码行作为度量标准的问题是它衡量解决方案的复杂性，而不是问题的复杂性＆＃34;

我相信引用来自David Parnas的ACM杂志上的一篇文章。

Answer 11

有很多不同的Software Metrics。代码行是最常用的，也是最容易理解的。

我很惊讶代码度量标准与其他指标的关联程度。除了购买可以计算圈复杂度的工具以发现代码气味之外，我只是寻找具有许多行的方法，并且它们往往也具有高复杂性。

使用代码行的一个很好的例子是指标：每行代码的错误。它可以让您直观地了解您应该在项目中找到多少错误。在我的组织中，我们通常每1000行代码大约20个错误。这意味着如果我们准备运送具有100,000行代码的产品，并且我们的错误数据库显示我们发现了50个错误，那么我们应该做更多的测试。如果我们每1000行代码有20个错误，那么我们可能正在接近通常的质量。

使用的一个不好的例子是衡量开发人员的生产力。如果您通过代码行来衡量开发人员的工作效率，那么人们倾向于使用更多的行来提供更少的代码。

Answer 12

答案：当你谈论负面的代码行时。如：“我今天删除了40行无关代码，程序仍然像以前一样运行。”

Answer 13

它在很多方面都很有用。

我不记得确切的＃但是微软有一个网络广播，每个X行代码都谈到平均有多少个错误。您可以使用该语句并使用它来为几个事项提供基线。

• 代码审核人员的工作表现如何。
• 通过比较几个项目的错误率来判断2名员工的技能水平。

我们看到的另一件事是，它为什么这么多线？通常，当新程序员陷入困境时，他们只会复制并粘贴代码块，而不是创建函数和封装。

---

我认为我在一天内编写x行代码是一种可怕的措施。它不会考虑问题的难度，写作的语言等等。

Answer 14

在我看来，我可以从任何给定项目中提到的代码行数有限。对于普通程序员来说，限制可能非常相似。因此，如果您知道您的项目有200万行代码，并且您的程序员可以期望能够理解错误是否与他们熟知的5K代码行有关，那么您知道需要雇用400代码库的程序员可以从某人的记忆中得到很好的覆盖。

这也会让你三思而后行，过快地增加你的代码库，并且可能会让你考虑重构它以使其更容易理解。

注意我编了这些数字。

Answer 15

我同意在项目中获取代码行总数是衡量复杂性的一种方法。

这当然不是衡量复杂性的唯一标准。例如，调试100行混淆的Perl脚本与使用注释模板调试5,000行Java项目有很大不同。

但是，如果不查看源代码，您通常会认为更多代码行更复杂，就像您可能认为10MB源代码压缩包比15kb源代码压缩包更复杂。

Answer 16

软件工程协会软件社区的流程成熟度简介：1998年年终更新（我遗憾地找不到链接）讨论了对大约800个软件开发团队（或者可能是商店）的调查。平均缺陷密度为每1000 LOC 12个缺陷。

如果你的应用程序有0个缺陷（它实际上不存在，但我们假设）并且写了1000个LOC，平均而言，你可以假设你刚刚在系统中引入了12个缺陷。如果QA发现1或2个缺陷就是这样，那么他们需要做更多的测试，因为可能还有10多个缺陷。

Answer 17

我写了两篇博文，详细说明了计算代码行（LoC）的利弊：

How do you count your number of Lines Of Code (LOC) ? ：我们的想法是解释您需要计算代码行的逻辑数量而不是物理数量。为此，您可以使用NDepend等工具。

Why is it useful to count the number of Lines Of Code (LOC) ?：我们的想法是，永远不应该使用LoC来衡量生产力，而是更多地使用测试覆盖率估算和软件期限估算。

Answer 18

这是吓跑/打动人的一个很好的衡量标准。这是关于它的，绝对是我在所有这三个例子中看到的背景。

Answer 19

这是生产力和复杂性的衡量标准。与所有指标一样，需要谨慎评估。单个指标通常不足以得到完整的答案。

IE，500线程序并不像5000线那么复杂。现在你必须提出其他问题才能更好地了解该计划...但现在你有一个指标。

Answer 20

当您需要预算需要订购的穿孔卡数量时。

Answer 21

当您想知道代码文件是否变得太大时，代码行很有用。嗯......这个文件现在是5000行代码。也许我应该重构一下。

Answer 22

当它与缺陷数量相关时，这是一个非常有用的想法。 “缺陷”为您提供代码质量的衡量标准。软件越少，“缺陷”越少;删除所有缺陷几乎是不可能的。在许多情况下，单一缺陷可能是有害的和致命的。

但是，似乎不存在非缺陷软件。

Answer 23

查看维基百科的定义：http://en.wikipedia.org/wiki/Source_lines_of_code

SLOC ='源代码行'

在我工作的这些指标中实际上有相当多的时间。还有不同的方法来计算SLOC。

来自维基百科的文章：

  

SLOC有两种主要类型   措施：物理SLOC和逻辑   SLOC。

另一个好资源：http://www.dwheeler.com/sloc/

Answer 24

正如大多数人已经说过的那样，它可能是一个模棱两可的指标，特别是如果你要比较不同语言的编码人员。

5,000行Lisp！= 5,000行C

Answer 25

确定努力程度（LOE）时。如果您正在整理提案，并且您将有大致相同的SAME工程师处理新项目，那么您可能能够确定需要多长时间的工程师。

Answer 26

当您重构代码库并且可以显示您删除代码行时，所有回归测试仍然通过。

Answer 27

当编码器不知道你在计算代码行时，所以没有理由故意添加冗余代码来游戏系统。当团队中的每个人都有类似的编码风格时（因此每行有一个已知的平均“价值”。）并且只有当你没有更好的衡量标准时才能使用。

Answer 28

代码行真的没那么有用，如果它被管理用作度量标准，它会导致程序员进行大量的重构以提高他们的分数。此外，糟糕的算法不会被简洁的短算法所取代，因为这会导致负的LOC计数对您不利。说实话，只是不要为使用LOC / d作为生产力指标的公司工作，因为管理层显然没有任何关于软件开发的线索，因此从第一天起你就会一直站在后面。

Answer 29

在比赛中。

Answer 30

指出为什么改变需要这么长时间。

“Windows是700万行代码，测试所有依赖项需要一段时间......”

Answer 31

在计算缺陷率（每1,000个LOC的错误等）时，LOC的数量很有用

Answer 32

始终。在这个问题上结束了新手。大师们大量而密集地编写代码。好的毕业生写了很多行但过多的绒毛。 Crappers复制代码行。所以，当然首先要做Tiles分析或门。

如果您的组织没有执行任何复杂点，特征点/功能点，提交或其他分析，则必须使用LoC。

任何告诉你不要用LoC衡量他或她的开发人员都很害羞。任何主曲柄代码我们就像你不相信。我和少数几个与普通程序员一样高效20倍到200倍的人工作过。而且他们的代码非常，非常，非常紧凑和高效。是的，就像Djystra一样，他们有很多心理模型。

最后，在任何事业中，大多数人并不擅长，大多数人都不擅长。编程也不例外。

是的，对任何大型项目进行命中分析，发现20％以上是死代码。再一次，主程序员经常消灭死代码和垃圾代码。

Answer 33

在比较语言时非常有用。我曾经在Groovy和Clojure中编写了一个小模块。 Clojure程序有大约250个loc和Groovy 1000 loc。有趣的是，当我查看一个复杂的函数并以类似的方式编写它时，它的行数完全相同。这表明Groovy代码被锅炉板填满，并给了我一些其他理由开始使用Clojure：）

正如其他一些人所说，在查看提交时也很好。如果您引入的代码行数多于已删除的代码行数，则需要注意增加了解决方案的复杂性。如果问题本身不会增加复杂性，这可能会让您重新考虑您的解决方案。如果你添加更多代码行，那么你可以通过自己来鼓励重构也是一件很好的事情，那么你应该花一些时间进行重构。

最后，虽然你可以通过努力减少loc来写一些难以阅读的东西，但是一个具有较少loc的解决方案几乎总是更容易阅读，因为阅读的内容更少。

Answer 34

我发现它在两个条件下很有用：

1. 当我的新项目缩短编码时间时，衡量我自己的工作效率。

2. 与一家大公司合作，并与每天真正了解小部件的经理交谈。

Answer 35

首先，我将排除生成的代码并添加生成器输入和生成器本身的代码。

我会说（有些讽刺的是），每行代码都可能包含一个bug并需要维护。要维护更多代码，您需要更多开发人员。从这个意义上说，更多的代码会带来更多就业机会。

我想从上面的声明中排除单元测试，因为较少的单元测试通常不会提高可维护性：）

Answer 36

代码行不是比较不同项目的有用指标。

但是，它可以在项目中用作移动数字，用于观察代码库的大小如何随时间变化。如果您在CI过程中生成一个图形，显示每个构建的代码行，它将帮助您可视化项目的演变过程。

即使在这种情况下，我也会认为确切的＆＃34;代码行＆＃34;数字本身并不重要;有用的是趋势的可视化 - 随着更多功能的增加，稳定向上攀升;大项目完成的跳跃;删除了一些冗余代码的逢低。

Answer 37

为给定任务添加的代码数量很大程度上取决于谁在编写代码。它不应该用作衡量生产力的指标。给定的个人可以产生1000行冗余和错综复杂的废话，同样的问题可以由10个简洁的代码行中的另一个人解决。当尝试使用LOC作为指标时，还应考虑“谁”因素。

实际有用的指标是“根据添加的行数找到的缺陷数”。这将为您提供给定团队或个人的编码和测试覆盖能力的指示。

正如其他人也指出的那样，LOC的删除权比LOC增加了更好的吹牛权：）

Answer 38

它们可以帮助表明应用程序的大小 - 对质量一无所知！我的观点是，如果你表明你曾经使用过1,000行的应用程序并且他们有一个500k行（大致）的应用程序，那么潜在的雇主可以理解你是否拥有大型系统经验而不是小型实用程序编程。

我完全同意warren的说法，你从系统中删除的代码行数比你添加的代码行更有用。

Answer 39

在销售演示期间经常使用此功能。例如，KLoC（Kilo代码行）或LoC用于证明供应商组织对大型/复杂系统的能力。当供应商试图展示其维护复杂遗留系统的能力时尤其如此。作为谈判的一部分，有时客户组织提供代表性的代码块以与供应商一起执行概念验证以测试供应商的能力。这个代表性代码将具有供供应商公司处理的足够复杂性以及其关于“维护”的销售宣传具有数百万LoC的系统“可以受到关注。

所以，是的，代码行在销售演示中被使用和滥用，因此是一个有用的销售指标。

Answer 40

代码行取决于语言。

例如，1行C代码值得平均为x行ASM代码。             1行C ++ - ＆gt; C 等....

由于VM的后台支持，Java和C＃封装了相当多的代码行。

Answer 41

这主要是对已经过量的评论的补充。但基本上，代码行（或者可能是totalCharacterCount / 60）表示怪物的大小。正如一些人所说，这给代码库的复杂性提供了线索。它的复杂程度有很大的影响。部分地，它影响了理解系统和进行改变的难度。

这就是为什么人们想要更少的代码行。理论上，较少的代码行不那么复杂，并且错误的可能性较小。我不确定知道前期对估算和规划以外的任何事情都非常有用。

例如：假设我有一个项目并且粗略检查我意识到这个问题将涉及在具有10,000行的应用程序中修改多达1000行代码。我知道这个项目可能需要更长的时间来实现，更不稳定，并且需要更长的时间来进行调试和测试。

它对于理解两个构建之间的变化范围也非常有用。我写了一个小程序，将分析任何两个SVN修订版之间的变化范围。它将查看统一的差异，并从中计算出添加，删除或更改了多少行。这有助于我了解在新版本之后的测试和QA中会发生什么。基本上，更多的变化意味着我们需要更密切地观察构建，通过完整的回归测试等等。

Answer 42

我听说微软过去常常每6个月解雇5％的人，我总是想象它会基于编写的代码行，这就是为什么Windows体积庞大，速度慢，效率低的原因;）。代码行是用于根据粗略排序测量应用程序复杂性的有用指标，即Basic中的初学者程序可能是10行代码，100行代码是玩具应用程序，50000行是合理大小的应用程序，10百万行代码是一种称为Windows的怪物。

代码行不是一个非常有用的度量标准，我曾经用汇编语言编写游戏（主要是68000），它们可以在大约50k行代码中进行测量，但是我通过不推动来减少代码行数注册到堆栈并跟踪寄存器中包含的内容以减少代码大小（我知道其他程序员将d0-d7，a0-a6多次推送到堆栈，这显然会降低代码速度，但会简化跟踪受影响的内容。

Answer 43

除了前面提到的“吹牛”目的外，功能上永远不会。

行！=有效性。根据我的经验，这种关系通常是相反的（虽然不是严格的，特别是极端的，显而易见的原因）

Answer 44

在将综合产品的广泛性推广给认为代码行是产品规模的一般指标的客户时，代码行数非常有用。例如，当您试图说服某人您的产品处理许多极端情况时，或者当您尝试进入开发工具的测试版时，工具供应商希望获得最大的代码覆盖率以用于测试目的。

Answer 45

对于风险评估而言，它可以很好地衡量复杂性 - 线路越多，引入错误的可能性就越大。