logo标签列表

“代码行数”何时有用作为度量标准？

metrics
56

有些人声称，代码的最大敌人就是代码量，我也倾向于这个观点。然而，每天你都会听到这样的话：

  • 我一天写了xxx行代码。
  • 我的项目有xxx行代码。
  • Windows 有 xxx 百万行代码。

问题：什么时候使用“#代码行数”有用？

注：当出现这种说法时，语气通常是“越多越好”。

7
当这个被写下来的时候，它在20年前很有用。我敢打赌它给观众留下了深刻印象。 - keyser
2
只是想添加这个关于误用此度量标准的经典故事。http://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt - Paul Bissex
45个回答
114

我会说它是当你删除代码以使项目运行更好的时候。

说你删除了“X行”的代码是很令人印象深刻的。并且比你添加了多少行代码更有帮助。

1
通过重构一些客户的遗留代码，例如在应用程序的主窗体中添加注释块，我能够将其行数减半。我猜这也算是自夸。 - Rob Allen
1
这个答案显然比本页上所有其他答案的总和都要好。感谢使用粗体字。 - dlamblin
2
删除的行数似乎只比添加的行数略微有用。它仍然很容易被操纵，因此不是一个非常有用的指标。 - Eli
1
我必须同意Eli的观点。如果仅仅通过删除来简化代码，你最终得到的代码看起来可能像Perl大师写的一样。虽然这可能会使项目运行得更好，但是你为稍后修改付出了巨大的开发时间和头疼之苦。 - Groxx
10
我曾经在一个长度为2200行的模块中删除了2100行代码，而没有改变任何功能。（这是针对某个非常粗心大意的复制黏贴程序员所留下的烂摊子进行整理......真是让人恼火） - Spudley
显示剩余5条评论
52

我很惊讶没有人提到迪杰斯特拉的名言，所以在这里说一下：

我的观点是，如果我们希望计算代码行数，我们不应该把它们看作“产出的行数”，而应该看作“花费的行数”：目前的常识是如此愚蠢，以至于在账簿的错误一边计算了这个数字。

这句话来自一篇名为“论计算机科学教学的残酷性”的文章。

38

这是一个糟糕的衡量标准，但正如其他人所指出的那样，它可以给你一个（非常）大概的系统整体复杂度的想法。如果你正在比较A和B两个项目，并且A有10,000行代码，而B有20,000行，那么这并不能告诉你太多——项目B可能过于冗长，或者A可能超级压缩。

然而，如果一个项目有10,000行代码，而另一个项目有1,000,000行代码，一般来说，第二个项目更加复杂。

这个指标的问题在于，当它用于评估生产力或对某个项目的贡献水平时，它就会出现问题。如果程序员“X”写的代码行数是程序员“Y”的两倍，他可能会或可能不会做出更多贡献——也许“Y”正在解决更难的问题……

4
与解决更难的问题相比，“Y”更可能是为同一个问题编写更好的代码，使其更加DRY和易维护。 - TM.
31

当向朋友炫耀时。

18
如果你和朋友吹嘘自己的代码行数，那么你需要多出去走走。有比你的代码库更有趣的事情值得吹嘘，哈哈:D - BenAlabaster
28

至少对于进展来说，不是这样的：

“以代码行数来衡量编程进展，就像以重量来衡量飞机制造进展一样。”--比尔·盖茨

22

有一个特殊的情况，我发现它是非常有价值的。当你在面试中，对方告诉你一部分工作是维护一个现有的C++/Perl/Java等老项目时。询问面试官遗留项目包含多少KLOC（约）将让你更好地了解是否想要这份工作。

在一些面试中，有时候会听到回答“我不知道”。 - EvilTeach
19

在加载行式打印机时，这很有用，这样你就知道即将要打印的代码清单将消耗多少页。

;)

10

这让我想起了这个:

这封信非常长，只因为我没有时间把它写得更短。
--布莱兹·帕斯卡。

（注：该段引用自法国数学家和哲学家布莱兹·帕斯卡的名言，强调写作的难度在于精简和压缩思想表达的内容。）
9
像大多数指标一样，如果没有上下文，它们的意义很小。所以简短的答案是：永远不要用这个指标来衡量代码质量（除了行打印机，那很有趣！但现在谁还会打印程序呢？）。
例如：
假设你正在对遗留代码进行单元测试和重构。它最初有50,000行代码（50 KLOC）和1,000个可证明的错误（失败的单元测试）。比率为1K/50KLOC = 每50行代码中有1个错误。显然这是糟糕的代码！
现在，经过几轮迭代后，通过出色的重构，你已经将已知的错误减少了一半（未知的错误可能更少），并且将代码库缩小了五倍。现在的比率是500/10000 = 每20行代码中有1个错误。这显然更糟糕了！
根据你想要产生的印象，可以选择以下一个或多个方面来描述：
- 减少了50%的错误 - 减少了5倍的代码 - 减少了80%的代码 - 错误与代码比率恶化了60%
所有这些陈述都是真实的（假设我没有搞错数学），但它们都无法总结出这种重构工作所取得的巨大改进。
然而，在几次迭代中，没有添加任何功能，而竞争对手的产品正在快速发展，这让你的公司很难有吸引更多投资的希望。 - graemeboy
功能被添加为其他微服务一样。任何需求变更都意味着这是另一个项目，应该作为一个独立的项目来处理。 - LogicDaemon
8

大约25年前，我读到一句话的意思是：

“使用代码行数作为衡量标准的问题在于它衡量的是解决方案的复杂度，而不是问题的复杂度。”

我相信这句话来自David Parnas在ACM期刊上的一篇文章。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接