有些人声称代码最大的敌人是它的大小，我倾向于同意。然而每天你都会听到诸如此类的事情
- 我一天就写了几行代码。
- 我拥有 x 行代码。
- Windows 是 x 百万行代码。
问题：“#lines of code”什么时候有用？
ps：注意，这种说法的时候，语气是“越多越好”。
问问题
30695 次
45 回答
112
我会说这是您删除代码以使项目运行得更好的时候。
说你删除了“X 行”是令人印象深刻的。而且比您添加的代码行更有帮助。
于 2008-10-08T18:14:48.927 回答
51
我很惊讶没有人提到 Dijkstra 的名言，所以这里是：
我今天的观点是，如果我们想计算代码行数，我们不应该将它们视为“产生的行数”，而是“花费的行数”：当前的传统智慧是如此愚蠢，以至于将其计入错误的一边分类帐。
引用来自一篇名为“论真正教授计算科学的残酷性”的文章。
于 2008-10-08T19:03:37.283 回答
37
这是一个糟糕的指标，但正如其他人所指出的，它让您对系统的整体复杂性有一个（非常）粗略的了解。如果你比较两个项目，A 和 B，A 是 10,000 行代码，B 是 20,000 行代码，这并不能告诉你太多 - 项目 B 可能过于冗长，或者 A 可能被超级压缩。
另一方面，如果一个项目是 10,000 行代码，而另一个是 1,000,000 行，那么第二个项目通常要复杂得多。
当这个指标被用来评估生产力或对某个项目的贡献水平时，就会出现问题。如果程序员“X”写的行数是程序员“Y”的 2 倍，他可能会或可能不会做出更多贡献——也许“Y”正在解决一个更难的问题......
于 2008-10-08T18:53:03.453 回答
29
跟朋友吹牛的时候。
于 2008-10-08T18:16:39.687 回答
28
至少，不是为了进步：
“通过代码行来衡量编程进度就像通过重量来衡量飞机制造进度。” - 比尔盖茨
于 2010-09-13T08:09:41.473 回答
21
当我发现它非常宝贵时，有一个特殊情况。当你在面试时，他们告诉你，你的部分工作将是维护现有的 C++/Perl/Java/等。遗留项目。询问面试官有多少 KLOC（大约）参与了遗留项目，会让你更好地了解你是否想要他们的工作。
于 2013-01-08T04:51:04.813 回答
19
它在加载行式打印机时很有用，这样您就知道要打印的代码列表将消耗多少页。;)
于 2008-10-08T18:48:07.673 回答
10
让我想起了这个：
这封信很长，只是因为我没有时间把它缩短。
——布莱斯·帕斯卡。
于 2010-11-23T14:26:28.303 回答
9
像大多数指标一样，它们在没有上下文的情况下意义不大。所以简短的回答是：从不（除了行式打印机，这很有趣！这些天谁打印出程序？）
一个例子：
想象一下，您正在对遗留代码进行单元测试和重构。它以 50,000 行代码（50 KLOC）和 1,000 个可证明的错误（失败的单元测试）开始。该比率为 1K/50KLOC = 每 50 行代码 1 个错误。显然这是一个糟糕的代码！
现在，经过多次迭代，通过示例性重构，您已将已知错误减少了一半（未知错误也减少了一半以上），代码库减少了五倍。该比率现在是 500/10000 = 每 20 行代码 1 个错误。这显然更糟！
根据您想要给人的印象，这可以呈现为以下一项或多项：
- 错误减少 50%
- 代码少五倍
- 减少 80% 的代码
- 错误代码比恶化 60%
所有这些都是正确的（假设我没有搞砸数学），并且它们都无法总结这种重构工作必须实现的巨大改进。
于 2008-10-08T19:10:45.070 回答
7
套用我大约 25 年前读过的一句话，
“使用代码行作为衡量标准的问题在于它衡量的是解决方案的复杂性，而不是问题的复杂性”。
我相信这句话出自 David Parnas 在 ACM 杂志上的一篇文章中。
于 2014-03-16T15:20:57.117 回答
5
有很多不同的软件指标。代码行是最常用的，也是最容易理解的。
我很惊讶代码行数指标与其他指标相关的频率。我没有购买可以计算圈复杂度的工具来发现代码异味，而是寻找具有许多行的方法，它们也往往具有很高的复杂性。
使用代码行的一个很好的例子是指标：每行代码的错误。它可以让您直观地了解您应该在项目中找到多少错误。在我的组织中，我们通常每 1000 行代码大约有 20 个错误。这意味着，如果我们准备发布具有 100,000 行代码的产品，并且我们的错误数据库显示我们发现了 50 个错误，那么我们可能应该进行更多测试。如果我们每 1000 行代码有 20 个错误，那么我们可能正在接近我们通常的质量。
一个不好的使用示例是衡量开发人员的生产力。如果您通过代码行来衡量开发人员的生产力，那么人们往往会使用更多的代码来交付更少的代码。
于 2008-10-08T18:31:09.283 回答
4
答：什么时候可以谈论负面的代码行。如：“我今天删除了 40 行无关的代码，程序仍然像以前一样运行。”
于 2008-10-08T18:15:19.987 回答
3
我同意获取项目中代码的总行数是衡量复杂性的一种方法。
这当然不是复杂性的唯一衡量标准。例如，调试一个 100 行的混淆 Perl 脚本与调试一个带有注释模板的 5,000 行 Java 项目有很大不同。
但是如果不查看源代码，您通常会认为代码行越多越复杂，就像您可能认为 10MB 源代码压缩包比 15kb 源代码压缩包更复杂一样。
于 2008-10-08T18:20:38.087 回答
3
它在很多方面都很有用。
我不记得确切的 # 但微软有一个网络广播，平均每 X 行代码就有 y 个错误。您可以使用该语句并使用它为几件事提供基线。
- 代码审查员的工作做得如何。
- 通过比较他们在几个项目中的错误率来判断 2 名员工的技能水平。
我们要看的另一件事是，为什么它有这么多行？很多时候，当一个新程序员陷入困境时，他们只会复制和粘贴代码块，而不是创建函数和封装。
我认为我在一天内写了 x 行代码是一个可怕的措施。它没有考虑问题的难度，你的写作语言等等。
于 2008-10-08T18:23:12.217 回答
3
在我看来，我可以从任何给定项目的头顶引用的代码行数是有限的。对于普通程序员来说，这个限制可能非常相似。因此，如果您知道您的项目有 200 万行代码，并且您的程序员能够理解错误是否与他们熟悉的 5K 行代码有关，那么您知道您需要雇用 400程序员可以很好地从某人的记忆中覆盖您的代码库。
这也会让你三思而后行，让你的代码库增长得太快，并可能让你考虑重构它以使其更易于理解。
注意我编造了这些数字。
于 2008-10-08T18:24:31.607 回答
3
软件工程学院的软件社区流程成熟度概况：1998 年年终更新（不幸的是，我找不到链接）讨论了对大约 800 个软件开发团队（或者可能是商店）的调查。平均缺陷密度为每 1000 LOC 12 个缺陷。
如果你有一个有 0 个缺陷的应用程序（它在现实中不存在，但让我们假设一下）并且平均写了 1000 个 LOC，你可以假设你刚刚在系统中引入了 12 个缺陷。如果 QA 发现 1 或 2 个缺陷仅此而已，那么他们需要进行更多测试，因为可能还有 10 多个缺陷。
于 2009-10-09T15:44:11.800 回答
2
当您想知道代码文件是否变得太大时，代码行很有用。嗯……这个文件现在有 5000 行代码。也许我应该重构这个。
于 2008-10-08T20:02:54.277 回答
2
当您必须为需要订购的打孔卡数量进行预算时。
于 2008-12-04T13:35:20.140 回答
2
它是生产力和复杂性的衡量标准。像所有指标一样，它需要谨慎评估。单个指标通常不足以提供完整的答案。
IE，一个 500 行的程序并不像 5000 行那么复杂。现在您必须提出其他问题才能更好地了解该程序……但是现在您有了一个指标。
于 2008-10-08T18:15:40.593 回答
2
这是吓唬/打动人们的一个很好的指标。就是这样，绝对是我在所有这三个例子中看到的上下文。
于 2008-10-08T18:15:48.987 回答
2
正如大多数人已经说过的那样，它可能是一个模棱两可的指标，尤其是在您比较使用不同语言编码的人时。
5,000 行 Lisp ！= 5,000 行 C
于 2010-04-28T00:44:22.573 回答
2
我写了 2 篇博文，详细说明了计算代码行数 (LoC) 的优缺点：
您如何计算代码行数 (LOC) ？：这个想法是为了解释你需要计算代码的逻辑行数而不是物理计数。为此，您可以使用NDepend等工具。
为什么计算代码行数 (LOC) 很有用？: 这个想法是永远不应该使用 LoC 来衡量生产力，而更多地用于测试覆盖率估计和软件截止日期估计。
于 2008-12-18T16:44:38.770 回答
2
总是。一堆新秀在这个问题上。大师们大量且密集地编写代码。好毕业生写了很多台词，但毛茸茸的太多了。垃圾复制代码行。所以，首先做一个 Tiles 分析或门，当然。
如果您的组织不进行任何复杂点、特征点/功能点、提交或其他分析，则必须使用 LoC。
任何告诉你不要用 LoC 衡量他或她的开发人员都是狗屎。任何大师级的曲柄都会像您一样编写我们的代码，您不会相信。我曾与少数人合作过，他们的工作效率是普通程序员的 20 倍到 200 倍。他们的代码非常、非常、非常紧凑和高效。是的，就像 Dijkstra 一样，他们有巨大的心智模型。
最后，在任何事业中，大多数人都不擅长，大多数人做的也不是很好。编程也不例外。
是的，对任何大型项目进行命中分析，发现 20% 以上是死代码。同样，高级程序员经常消灭死代码和垃圾代码。
于 2017-10-04T20:41:49.407 回答
1
当您重构代码库并且可以显示您删除了代码行时，所有回归测试仍然通过。
于 2008-10-08T18:15:32.950 回答
1
代码行实际上并没有那么有用，如果它被管理层用作衡量标准，它会导致程序员进行大量重构以提高他们的分数。此外，糟糕的算法不会被简洁的短算法取代，因为这会导致负 LOC 计数对您不利。老实说，不要为使用 LOC/d 作为生产力指标的公司工作，因为管理层显然对软件开发一无所知，因此您从第一天起就总是处于不利地位。
于 2008-10-08T18:23:20.063 回答
1
当指出为什么改变需要这么长时间时。
“Windows 是 700 万行代码，测试所有依赖项需要一段时间……”
于 2008-10-08T18:29:58.320 回答
1
在比赛中。
于 2008-10-08T18:34:09.747 回答
1
当编码人员不知道您在计算代码行数时，因此没有理由故意添加冗余代码来玩弄系统。当团队中的每个人都有相似的编码风格时（所以每行都有一个已知的平均“价值”。）只有当你没有更好的衡量标准时。
于 2008-10-08T18:38:26.633 回答
1
查看维基百科的定义：http ://en.wikipedia.org/wiki/Source_lines_of_code
SLOC = '源代码行'
实际上，我在这些指标上投入了相当多的时间。计算 SLOC 也有不同的方法。
来自维基百科文章：
有两种主要类型的 SLOC 度量：物理 SLOC 和逻辑 SLOC。
另一个很好的资源：http ://www.dwheeler.com/sloc/
于 2008-10-08T19:09:36.523 回答
1
它们可以帮助指示应用程序的大小 - 与质量无关！我的意思是，如果您指出您从事的应用程序有 1,000 行，而他们的应用程序有 500k 行（大约），那么潜在雇主可以理解您是否有大型系统经验与小型实用程序编程。
我完全同意沃伦的观点，即从系统中删除的代码行数比添加的行数更有用。
于 2008-10-08T19:51:03.117 回答
1
在确定努力水平 (LOE) 时。如果您正在制定一个提案，并且您将有大致相同的工程师在新项目上工作，那么您可能能够确定需要多少工程师多长时间。
于 2014-03-07T18:26:36.043 回答
1
当它与缺陷数量相关时，这是一个非常有用的想法。“缺陷”为您提供代码质量的衡量标准。“缺陷”越少，软件就越好；几乎不可能消除所有缺陷。在许多情况下，一个单一的缺陷可能是有害的和致命的。
但是，似乎不存在无缺陷的软件。
于 2012-05-16T09:08:17.140 回答
0
除了前面提到的“吹牛”目的之外，从功能上讲永远不会。
行！=有效性。根据我的经验，这种关系通常是相反的（尽管不严格，尤其是极端情况，原因很明显）
于 2008-10-09T04:09:50.583 回答
0
代码行数取决于语言。
例如，1 行 C 代码平均相当于 x 行 ASM 代码。1 行 C++ -> C 等....
由于 VM 的背景支持，Java 和 C# 封装了相当多的代码行。
于 2009-10-09T15:36:50.083 回答
0
我发现它在两种情况下很有用：
当编码时间减少时，在我自己的新项目中衡量我自己的生产力。
在与一家大公司合作并与一位真正每天只了解小部件的经理交谈时。
于 2008-10-08T18:18:41.367 回答
0
首先，我将排除生成的代码并添加生成器输入的代码和生成器本身。
然后我会说（有点讽刺），每一行代码都可能包含一个错误并且需要维护。要维护更多代码，您需要更多的开发人员。从这个意义上说，更多的代码会产生更多的就业机会。
我想从上面的陈述中排除单元测试，因为较少的单元测试通常不会提高可维护性:)
于 2008-10-08T18:19:48.200 回答
0
为给定任务添加的代码数量很大程度上取决于编写代码的人。它不应该被用作生产力的衡量标准。一个给定的人可以产生 1000 行冗余和复杂的废话，而同样的问题可以由另一个人用 10 行简洁的代码来解决。在尝试使用添加的 LOC 作为指标时，还应考虑“谁”因素。
一个实际有用的指标是“发现的缺陷数量与添加的行数”。这将使您了解给定团队或个人的编码和测试覆盖能力。
正如其他人也指出的那样，删除的 LOC 比添加的 LOC 具有更好的吹牛权:)
于 2008-10-08T18:27:45.063 回答
0
这主要是对已经大量评论的补充。但基本上，代码行数（或者可能是 totalCharacterCount/60）表示怪物的大小。正如一些人所说，这为代码库的复杂性提供了线索。它的复杂程度有很大的影响。它在一定程度上影响了理解系统和做出改变的难度。
这就是为什么人们想要更少的代码行。从理论上讲，代码行数越少，复杂性就越小，出错的空间也就越小。我不确定知道预先知道对估计和计划以外的任何事情都非常有用。
例如：假设我有一个项目，经过粗略的检查，我意识到这将涉及在一个有 10,000 行的应用程序中修改多达 1000 行代码。我知道这个项目可能需要更长的时间来实现，不太稳定，并且需要更长的时间来调试和测试。
它对于理解两个构建之间的变化范围也非常有用。我写了一个小程序来分析任何两个 SVN 版本之间的变化范围。它将查看一个统一的差异，并从中找出添加、删除或更改了多少行。这有助于我了解在新版本之后的测试和 QA 中会发生什么。基本上，更大数量的变化意味着我们需要更密切地观察构建，通过完整的回归测试等。
于 2008-10-08T18:44:54.343 回答
0
我听说微软过去每 6 个月解雇 5% 的人，我一直认为这将基于编写的代码行数，这就是为什么 Windows 如此庞大、缓慢和低效的原因;)。代码行数是衡量应用程序在粗略排序方面复杂性的有用指标，即 Basic 中的初学者程序可能是 10 行代码，100 行代码是玩具应用程序，50000 行是合理大小的应用程序，10百万行代码是一个叫做 Windows 的怪物。
代码行数不是一个非常有用的指标，我曾经用汇编语言（主要是 68000 行）编写游戏，它们的代码行数约为 50k，但我通过不将寄存器推送到堆栈并跟踪寄存器中包含的内容以减少代码大小（我认识的其他程序员将 d0-d7、a0-a6 的倍数推送到堆栈，这显然会减慢代码速度，但简化了跟踪有什么影响）。
于 2008-10-08T19:07:45.607 回答
0
出于风险评估的目的，它可以很好地衡量复杂性 - 更改的行越多，引入错误的机会就越大。
于 2008-10-08T19:10:16.367 回答
0
在向将代码行数视为产品大小一般指标的客户推销综合产品的广泛性时，代码行数非常有用。例如，当您试图说服某人您的产品处理许多极端情况时，或者当您试图进入开发工具的测试版时，工具供应商希望获得最大的代码覆盖率以进行测试。
于 2008-10-08T20:42:47.287 回答
0
这在销售演示中经常使用。例如，KLoC（Kilo Lines of Code）或 LoC 用于展示供应商组织对大型/复杂系统的能力。当供应商试图展示他们维护复杂遗留系统的能力时，尤其如此。作为谈判的一部分，有时客户组织会提供代表代码块来与供应商一起执行概念证明，以测试供应商的能力。该代表代码将具有足够的复杂性供供应商公司处理，并且其关于“维护”的宣传具有数百万 LoC 的系统可能会受到关注。
所以，是的，代码行在销售演示中被使用和滥用，因此是销售中的一个有用指标。
于 2009-10-29T08:38:03.477 回答
0
LOC 的数量在计算缺陷率（每 1,000 LOC 的错误等）时很有用
于 2010-09-13T07:55:25.280 回答
0
代码行数不是比较不同项目的有用指标。
但是，它可以在项目中用作移动图形，用于观察代码库的大小如何随时间变化。如果您生成一个图表作为 CI 过程的一部分，显示每次构建时的代码行，它将帮助您可视化项目的发展方式。
即使在这种情况下，我也认为确切的“代码行”数字本身并不重要。有用的是趋势的可视化 - 随着更多功能的添加，稳步向上攀升；大项目完成的跳跃；删除了一些冗余代码的下降。
于 2012-05-16T20:41:03.380 回答
0
在比较语言时它可能很有用。我曾经用 Groovy 和 Clojure 写过一个小模块。Clojure 程序有大约 250 个 loc，而 Groovy 有 1000 个 loc。有趣的是，当我查看一个复杂函数并以类似的方式编写它时，它的行数完全相同。这表明 Groovy 代码被样板填满，并给了我一些开始使用 Clojure 的额外理由：)
正如其他人所说，查看提交时也很好。如果您引入的代码行数多于删除的代码行数，那么您需要意识到您增加了解决方案的复杂性。如果问题本身不会增加复杂性，这可能会让您重新考虑您的解决方案。与自己做一个很好的协议来鼓励重构，如果你添加更多的代码行，那么你应该花一些时间进行重构。
最后，尽管您可以通过努力减少 loc 来编写难以阅读的内容，但具有较少 loc 的解决方案几乎总是更容易阅读，因为阅读的内容更少。
于 2015-03-09T13:27:22.660 回答