lines-of-code - 有没有一种标准的方法来计算代码行数？

Question

我意识到这个问题没有绝对“正确”的答案，但是当人们谈论代码行时，它们是什么意思？例如，在 C++ 中，你计算空行吗？评论？只有开括号或闭括号的行？

我知道有些人使用代码行作为生产力衡量标准，我想知道这里是否有标准约定。另外，我认为有一种方法可以让各种编译器计算代码行数——那里有标准约定吗？

score 23 · Accepted Answer

不，没有标准约定，每个计算它们的工具都会略有不同。

这可能会让您问：“那我为什么要使用 LOC 作为生产力衡量标准呢？” 答案是，因为你如何计算一行代码并不重要，只要你一致地计算它们，你就可以对一个项目相对于其他项目的总体规模有所了解。

score 14 · Accepted Answer

有两种主要类型的 SLOC 度量：物理 SLOC 和逻辑 SLOC。这两种度量的具体定义各不相同，但物理 SLOC 最常见的定义是程序源代码文本中的行数，包括注释行。除非一节中的代码行包含超过 25% 的空行，否则空行也包括在内。在这种情况下，超过 25% 的空白行不计入代码行数。

逻辑 SLOC 度量试图度量“语句”的数量，但它们的具体定义与特定的计算机语言相关（对于类 C 编程语言的一个简单的逻辑 SLOC 度量是语句终止分号的数量）。创建测量物理 SLOC 的工具要容易得多，并且物理 SLOC 定义更容易解释。但是，物理 SLOC 度量对逻辑上不相关的格式和样式约定敏感，而逻辑 SLOC 对格式和样式约定不太敏感。不幸的是，SLOC 度量通常在没有给出定义的情况下被陈述，并且逻辑 SLOC 通常与物理 SLOC 有很大不同。

考虑以下 C 代码片段作为确定 SLOC 时遇到的歧义的示例：
for (i=0; i<100; ++i) printf("hello");   /* How many lines of code is this? */
在这个例子中，我们有：

1 物理代码行 LOC

2 逻辑代码行 lLOC（for 语句和 printf 语句）

1 条评论行

[...]

score 8 · Accepted Answer

我会说

评论数
空行很重要，因为它们对可读性很重要，但连续不超过一个
带大括号的行也算，但应用与空行相同的规则 - 即 5 个嵌套大括号之间没有代码算作一行。

我还谦虚地建议，任何实际上依赖于 LoC 值的生产力衡量标准都是愚蠢的 :)

score 4 · Accepted Answer

4

无论“wc -l”返回什么都是我的号码。

于 2008-12-09T16:36:23.077 回答

score 4 · Accepted Answer

任何一天我可以用更少的代码行结束，但有更多或更多的工作功能......是美好的一天。能够删除数百行代码并最终得到功能相同且更易于维护的东西，这是一件很棒的事情。

话虽如此，除非您的团队中有非常严格的编码准则，否则物理代码行数是无用的统计数据。逻辑代码行仍然没有用，但至少它不会产生危险的误导。

score 2 · Accepted Answer

“代码行”应包括您必须维护的任何内容。这包括注释，但不包括空格。

如果您将此用作生产力指标，请确保您进行了合理的比较。一行 C++ 与一行 Ruby 不同。

score 2 · Accepted Answer

如果你使用 LOC 作为生产力的衡量标准，你会突然发现你的程序员写得更加冗长以“玩弄系统”。这是一个愚蠢的措施，只有愚蠢的人才会用它来炫耀。

score 2 · Accepted Answer

1 行 = 4 秒的阅读时间。如果需要更多的时间来弄清楚我在那条线上所说的话，那这条线就太长了。

score 1 · Accepted Answer

LOC 是一个出了名的模棱两可的指标。对于详细的比较，它仅在比较由同一团队以相同语言、相同风格编写的代码时才有效。

但是，当从数量级的想法来看时，它确实提供了一定的复杂性概念。10000 行程序比 100 行程序复杂得多。

LOC 的优点是 wc -l 返回它，与许多其他软件指标不同，在理解或计算它时没有真正的花哨。

score 1 · Accepted Answer

没有正确的答案。

对于非正式的估计，我使用 wc -l。

如果我需要严格衡量某些东西，我会衡量可执行语句。几乎所有带有语句终止符（通常是分号）或以块结尾的东西。对于复合语句，我会计算每个子语句。

所以：

int i = 7;                  # one statement terminator; one (1) statement
if (r == 9)                # count the if as one (1) statement
  output("Yes");      # one statement terminator; one (1) statement; total (2) for the if
while (n <= 14) {    # count the while as one (1) statement
  output("n = ", n);  # one statement terminator; one (1) statement
  do_something();   # one statement terminator; one (1) statement
  n++                       # count this one, one statement (1), even though it doesn't need a statement terminator in some languages
}                              # brace doesn't count; total (4) for the while

如果我在 Scheme 或 Lisp 中做这件事，我会计算表达式。

正如其他人所说，最重要的是您的计数是一致的。您将其用于什么也很重要。如果您只想让潜在的新员工知道您的项目有多大，请使用 wc -l。如果你想做计划和估计，那么你可能想要更正式一些。在任何情况下，您都不应该使用 LOC 来作为程序员薪酬的基础。

score 1 · Accepted Answer

您应该考虑“花费的代码行”，而不是“产生的代码行”。

事情应该尽可能简单，因此基于行数创建一个积极的基准会鼓励糟糕的代码。

此外，一些非常困难的事情最终可以用很少的代码解决，而一些非常容易的事情（例如 getter 和 setter 的样板代码）可以在很短的时间内添加很多行。

至于最初的问题，如果我要计算行数，我会包括连续空行以外的每一行。我也会包含评论，因为它们（希望）是有用的文档。

score 1 · Accepted Answer

LOC 的概念是尝试量化代码量。正如其他答案中所指出的，只要您保持一致，您具体调用代码行的内容并不重要。直观地说，似乎一个 10 行程序小于一个 100 行程序，它小于一个 1000 行程序等等。您会期望创建、调试和维护 100 行程序比 1000 行程序花费更少的时间。至少非正式地，您可以使用 LOC 大致了解创建、调试和维护特定大小的程序所需的工作量。

当然，也有不成立的地方。例如，用 1000 行呈现的复杂算法可能比使用 2500 行的简单数据库程序更难开发。

因此，LOC 是一种粗粒度的代码量度量，它使管理人员能够合理地了解问题的大小。

score 0 · Accepted Answer

LOCphy：物理线
LOCbl: Blanklines Kommentarblocks werden 饰演 Kommentarzeile gezählt
LOCpro：编程线（声明、定义、指令和代码）
LOCcom：评论行

许多可用的工具都提供了填充线的百分比等信息。

你只需要看看它，但不要只指望它。

LOC 在项目开始时大幅增长，并且在审查后经常减少；）

score 0 · Accepted Answer

我认为它是一个单一的可处理语句。例如

(1 行)

Dim obj as Object

(5 行)

If _amount > 0 Then
  _amount += 5
Else
  _amount -= 5
End If

score 0 · Accepted Answer

我同意那些说它以多种方式报告并且不是重要指标的帖子。看到这个ever-hear-of-developers-getting-paid-paid-per-line-of-code。

score 0 · Accepted Answer

我同意 Craig H 接受的答案，但是我想补充一点，在学校里，我被教导说，在衡量代码行数时，不应将空格、注释和声明算作“代码行数”由程序员出于生产力目的而制作 - 即“每天 15 行”规则。

score 0 · Accepted Answer

我wc -l用于快速估计工作空间的复杂性。但是，作为生产力指标 LOC 是最差的。如果我的 LOC 计数下降，我通常认为这是非常有成效的一天。

score 0 · Accepted Answer

我知道有些人使用 LoC 作为生产力衡量标准

你能告诉我他们是谁，这样我就不会意外地和他们一起工作（或者更糟的是，为他们工作）吗？

如果我可以使用 Haskell 在 1400 行中实现我也可以使用 C 在 2800 行中实现，那么我在 C 或 Haskell 中的效率更高吗？哪个需要更长的时间？哪个会有更多的错误（提示：它在 LOC 计数中是线性的）？

程序员的价值在于他的代码更改（包括从空字符串更改或更改为空字符串）增加了您的底线数字。我知道没有好的方法来衡量或近似它。但我知道任何可以合理衡量的指标都可以被玩弄，并不能反映你真正想要的。所以不要使用它。

话虽如此，您如何计算 LOC？很简单，用wc -l。为什么这是正确的工具？好吧，您可能不关心任何特定的数字，而是关心总体总体趋势（上升或下降，以及多少）、个别趋势（上升或下降、改变方向的速度……）以及除了数字 82,763 之外，几乎所有内容。

工具测量的内容之间的差异可能并不有趣。除非您有证据表明您的工具（并且只有该工具）吐出的数字与有趣的事物相关，否则将其用作粗略的大致数字；除了单调性之外，任何东西都应该不仅与一粒谷物一起服用，还应与一桶盐一起服用。

计算发生了多少次'\n'。其他有趣的字符可能是';','{'和'/'。

score 0 · Accepted Answer

在 .NET 世界中，似乎有一个全球性的协议，即一行代码 (LoC) 是一个调试序列点。序列点是一个调试单元，它是放置断点时以深红色突出显示的代码部分。使用序列点，我们可以谈论逻辑 LoC，并且可以在各种 .NET 语言之间比较该指标。大多数 .NET 工具都支持逻辑 LoC 代码度量，包括 VisualStudio 代码度量、NDepend 或 NCover。

一种 8 LoC 方法（不考虑开始和结束括号序列点）：

替代文字

与物理 LoC（仅计算源文件中的行数）相反，逻辑 LoC 具有不依赖于编码风格的巨大优势。我们都同意，编码风格可以使物理 LoC 计数从一个开发人员到另一个开发人员变化一个数量级。我写了一篇关于这个主题的更详细的博客文章：你如何计算你的代码行数（LOC）？

score 0 · Accepted Answer

用 LOC 来衡量一个程序员的表现，就像是根据一幅画的大小来判断一幅画的好坏。就我而言，LOC 的唯一“价值”是给您的客户留下深刻印象并吓跑您的竞争对手。

也就是说，我认为编译指令的数量是最不模糊的。尽管如此，糟糕的程序员的优势在于他们倾向于编写不必要的冗长代码。我记得曾经用 28 行代码替换了 800 多行非常糟糕的代码。这会让我变得懒惰吗？

任何使用 LOC 作为主要性能指标的项目经理都是白痴，应该得到糟糕的程序员。

score 0 · Accepted Answer

我强烈推荐 cloc 工具来完成这项工作。它计算了许多语言的行数。

https://github.com/AlDanial/cloc#quick-start-

我为我们公司使用过并且喜欢这个工具。我将分享来自输出的 ss；

lines-of-code - 有没有一种标准的方法来计算代码行数？

21 回答 21

Related

Reference