我意识到这个问题没有绝对“正确”的答案，但是当人们谈论代码行时，它们是什么意思？例如，在 C++ 中，你计算空行吗？评论？只有左大括号或右大括号的行？
我知道有些人使用代码行来衡量生产力，我想知道这里是否有标准约定。另外，我认为有一种方法可以让各种编译器计算代码行数——那里有标准约定吗？
【问题讨论】：
标签： lines-of-code
不，没有标准约定，每个计算它们的工具都会略有不同。
这可能会让您问：“为什么我会使用 LOC 作为生产力衡量标准？”答案是，因为你如何计算一行代码并不重要，只要你一致地计算它们，你就可以对一个项目相对于其他项目的总体规模有所了解。
【讨论】：
看看Wikipedia Article，尤其是“Measuring SLOC”部分：
有两种主要类型的 SLOC 措施：物理 SLOC 和逻辑 SLOC。这些的具体定义 两种措施各不相同，但最常见的 物理 SLOC 的定义是一个计数 程序文本中的行数 源代码，包括注释行。 空行也包括在内，除非 一节中的代码行 包含超过 25% 的空白行。 在这种情况下，空行超过 25% 不计入 代码。
逻辑 SLOC 措施试图 测量“语句”的数量， 但他们的具体定义是 绑定到特定的计算机语言 （一个简单的逻辑 SLOC 测量 类 C 的编程语言是 语句终止数 分号）。这要容易得多 创建测量物理的工具 SLOC 和物理 SLOC 定义 更容易解释。然而， 物理 SLOC 措施很敏感 逻辑上不相关的格式和 样式约定，而逻辑 SLOC 对格式不太敏感，并且 样式约定。不幸的是，SLOC 措施往往没有说明 给出他们的定义和逻辑 SLOC 通常可以显着 不同于物理 SLOC。
将这个 C 代码的 sn-p 视为 遇到歧义的例子 确定 SLOC 时：
for (i=0; i<100; ++i) printf("hello"); /* How many lines of code is this? */在这个例子中，我们有：
- 1 物理代码行 LOC
- 2 逻辑代码 lLOC 行（用于语句和 printf 语句）
- 1 条评论行
[...]
【讨论】：
我会说
我还谦虚地建议，任何实际依赖于 LoC 值的生产力衡量标准都是愚蠢的 :)
【讨论】：
任何一天我可以以更少的代码行结束，但工作功能一样多或更多......是美好的一天。能够删除数百行代码并最终得到功能相同且更易于维护的东西，这是一件很棒的事情。
话虽如此，除非您的团队中有非常严格的编码准则，否则物理代码行数是无用的统计数据。逻辑代码行仍然没用，但至少不会造成危险的误导。
【讨论】：
“wc -l”返回的是我的号码。
【讨论】：
“代码行”应包括您必须维护的所有内容。这包括 cmets，但不包括空格。
如果您将此用作生产力指标，请确保您进行了合理的比较。一行 C++ 和一行 Ruby 是不一样的。
【讨论】：
如果您使用 LOC 作为生产力的衡量标准，您会突然发现您的程序员写得更加冗长以“玩弄系统”。这是一个愚蠢的措施，只有愚蠢的人才会用它来炫耀。
【讨论】：
1 行 = 4 秒的阅读时间。如果需要更多的时间才能弄清楚我在那条线上说的是什么，那这条线就太长了。
【讨论】：
LOC 是一个出了名的模棱两可的指标。对于详细的比较，它仅在比较由同一团队以相同语言、相同风格编写的代码时才有效。
但是，从数量级的概念来看，它确实提供了某种复杂性概念。 10000 行程序比 100 行程序复杂得多。
LOC 的优点是 wc -l 返回它，与许多其他软件指标不同，理解或计算它并没有真正的花哨。
【讨论】：
没有正确答案。
对于非正式的估计，我使用 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 来作为程序员薪酬的基础。
【讨论】：
您应该考虑“代码行花费”，而不是“代码行产生”。
事情应该尽可能简单，因此根据行数创建积极的基准会鼓励糟糕的代码。
此外，一些非常困难的事情最终只需要很少的代码就可以解决，而一些非常容易的事情（例如 getter 和 setter 等样板代码）可以在很短的时间内添加很多行。
至于最初的问题，如果我要计算行数，我会包括连续空行以外的每一行。我也会包括 cmets，因为它们（希望）是有用的文档。
【讨论】：
LOC 的概念是尝试量化大量代码。正如在其他答案中所指出的，只要您保持一致，您具体调用代码行的内容并不重要。直观地说，似乎一个 10 行程序小于一个 100 行程序，它小于一个 1000 行程序等等。您会期望创建、调试和维护 100 行程序比 1000 行程序花费更少的时间。至少非正式地，您可以使用 LOC 大致了解创建、调试和维护特定大小的程序所需的工作量。
当然，有些地方不成立。例如，用 1000 行呈现的复杂算法可能比使用 2500 行的简单数据库程序更难开发。
因此，LOC 是一种粗粒度的代码量度量，它使管理人员能够合理地了解问题的规模。
【讨论】：
我使用wc -l 来快速估计工作空间的复杂性。
但是，作为生产力指标，LOC 是 最糟糕的。
如果我的 LOC 计数下降，我通常认为这是非常有成效的一天。
【讨论】：
许多可用的工具都提供了填充线的百分比等信息。
你只需要看看它，但不要只指望它。
LOC 在项目开始时大幅增长，但在审查后经常下降；）
【讨论】：
我认为它是一个可处理的语句。例如
（1 行）
Dim obj as Object
（5 行）
If _amount > 0 Then
_amount += 5
Else
_amount -= 5
End If
【讨论】：
我同意那些说它以多种方式被报告并且不是一个重要指标的帖子。看到这个ever-hear-of-developers-getting-paid-per-line-of-code。
【讨论】：
我同意 Craig H 接受的答案，但我想补充一点，在学校里，我被教导说，在衡量程序员出于生产力目的而编写的代码行——即“每天 15 行”规则。
【讨论】：
我知道有些人使用 LoC 作为生产力衡量标准
你能告诉我他们是谁，这样我就不会意外地和他们一起工作（或者更糟的是，为）他们？
如果我可以使用 Haskell 在 1400 行中实现我也可以使用 C 在 2800 行中实现，那么我在 C 或 Haskell 中的效率更高吗？哪个需要更长的时间？哪个会有更多的错误（提示：它在 LOC 计数中是线性的）？
程序员的价值在于他的代码更改（包括从空字符串更改或更改为空字符串）增加了您的底线数字。我知道没有好的方法来衡量或近似它。但我知道任何可以合理衡量的指标都可以被玩弄，并不能反映你真正想要的。所以不要使用它。
话虽如此，您如何计算 LOC？很简单，使用wc -l。为什么这是正确的工具？好吧，您可能不关心任何特定的数字，而是关心总体总体趋势（上升或下降，以及多少），个人趋势（上升或下降，改变方向的速度……）以及除了数字 82,763 之外，几乎所有内容。
工具测量的内容之间的差异可能并不有趣。除非您有证据表明您的工具（并且仅该工具）吐出的数字与有趣的事物相关，否则请将其用作粗略的大致数字；除了单调性之外的任何东西都应该与一粒谷物和一桶盐一起服用。
计算'\n' 出现了多少次。其他有趣的字符可能是';'、'{' 和'/'。
【讨论】：
在 .NET 世界中似乎全球一致认为一行代码 (LoC) 是一个调试序列点。序列点是一个调试单元，它是放置断点时以深红色突出显示的代码部分。使用序列点，我们可以谈论 逻辑 LoC，并且可以在各种 .NET 语言之间比较这个指标。大多数 .NET 工具都支持逻辑 LoC 代码度量，包括 VisualStudio 代码度量、NDepend 或 NCover。
8 LoC 方法（不考虑开始和结束括号序列点）：
与物理 LoC（仅计算源文件中的行数）相反，逻辑 LoC 具有不依赖于编码风格的巨大优势。我们都同意，编码风格可以使物理 LoC 计数从一个开发人员到另一个开发人员变化一个数量级。关于这个话题我写了一篇更详细的博文：How do you count your number of Lines Of Code (LOC) ?
【讨论】：
使用 LOC 来衡量一个程序员的表现就像是通过它的大小来判断一幅画的质量。就我而言，LOC 的唯一“价值”是给您的客户留下深刻印象并吓跑您的竞争对手。
也就是说，我认为编译指令的数量是最不模糊的。尽管如此，糟糕的程序员的优势在于他们倾向于编写不必要的冗长代码。我记得曾经用 28 行代码替换了 800 多行非常糟糕的代码。这会让我变得懒惰吗？
任何将 LOC 用作主要性能指标的项目经理都是白痴，应该得到糟糕的程序员。
【讨论】：
我强烈推荐 cloc 工具来完成这项工作。它计算多种语言的行数。
https://github.com/AlDanial/cloc#quick-start-
我在我们公司使用过并且喜欢这个工具。我将分享一个来自输出的 ss；
【讨论】：