您如何计算代码行数（LOC）？

Question

虽然LOC（＃行代码）是对代码复杂性的有问题的衡量，但它是最受欢迎的，并且当非常小心地使用时，可以提供对代码库的至少相对复杂性的粗略估计（即，如果一个程序是10KLOC，另一个是100KLOC，用相同的语言编写，由具有相同能力的团队编写，第二个程序几乎肯定要复杂得多。）

在计算代码行时，您是否更愿意计算注释？测试怎么样？

我见过各种方法。像cloc和sloccount这样的工具允许包含或排除注释。其他人认为评论是代码的一部分及其复杂性。

单元测试存在同样的困境，有时可以达到测试代码本身的大小，甚至超过它。

我已经看到了整个范围内的方法，从仅计算“操作”非评论非空白行到“XXX行测试，评论代码”，这更像是在所有代码上运行“wc -l”项目中的文件“。

您的个人偏好是什么？为什么？

Answer 1

在管理程序员方面，一位聪明人告诉我“你得到的是你所得到的”。

如果你在他们的LOC输出中对它们进行惊人的评分，你会得到很多代码。

如果你根据他们关闭的错误数量对它们进行评分，那么你会发现很多错误。

如果您对添加的功能进行评分，则会获得很多功能。

如果你根据圈复杂度对它们进行评分，你会得到非常简单的函数。

由于现在代码基础的一个主要问题是它们的增长速度以及它们一旦发展变化有多么难以改变，我倾向于回避使用LOC作为指标，因为它驱动了错误的基本行为。

也就是说，如果你必须使用它，那么无需评论和测试，并且需要一致的编码风格。

但是，如果你真的想要一个'代码大小'的度量，只需tar.gz代码库。它倾向于作为对“内容”的更好的粗略估计，而不是计算易受不同编程风格影响的行。

Answer 2

也必须保持测试和评论。如果你打算使用LOC作为一个指标（我只是假设我不能告诉你），你应该给出所有三个（实际代码，注释，测试行）。

最重要的（也是显而易见的）事情是你保持一致。不要仅使用实际代码行报告一个项目，而将所有三个项目组合起来报告另一个项目。查找或创建一个工具，为您自动执行此过程并生成报告。

Lines of Code:       75,000
Lines of Comments:   10,000
Lines of Tests:      15,000
                  ---------
Total:              100,000

这样你就可以确定

了

完成。
每次都以同样的方式完成。

Answer 3

我个人认为LOC指标本身并不像其他一些代码指标那样有用。

NDepend会为您提供LOC指标，但也会为您提供许多其他指标，例如周期性复杂性。不是列出所有内容，而是列表中的link。

CodeMetric add-in

还有免费Reflector

Answer 4

我不会直接回答你的问题，原因很简单：我讨厌代码行度量标准。无论你想要测量什么，都很难比LOC更糟糕;几乎任何你想到的其他指标都会更好。

特别是，您似乎希望衡量代码的复杂性。整体cyclometric complexity（也称为McCabe的复杂性）是更好的指标。

具有高周期复杂度的例程是您希望关注的例程。这些例程难以测试，因为存在缺陷而难以维护。

有许多工具可以衡量这种复杂性。快速谷歌搜索您最喜欢的语言将找到许多这种复杂性的工具。

Answer 5

代码行意味着：不计算任何评论或空行。并且为了使其与其他源代码相当（无论其中的度量标准是否有用），您至少需要类似的编码样式：

for (int i = 0; i < list.count; i++)
{
    // do some stuff
}

for (int i = 0; i < list.count; i++){
    // do some stuff
}

第二个版本完全相同，但有一个LOC少。当你有很多嵌套循环时，这可以总结一下。这就是function points等指标的发明原因。

Answer 6

取决于您使用LOC的目的。

作为一项复杂措施 - 并非如此。也许100KLOC主要是从一个简单的表生成的代码，以及10KLOC kas 5KLOC regexps。

但是，我看到每行代码与运行成本相关联。只要程序存在，您就需要支付每一行：它需要在维护时读取，它可能包含需要修复的错误，它会增加编译时间，从源代码控制和备份时间，在您更改之前或者删除它你可能需要找出是否有人依赖它等。平均成本可能是每行和每天nanopennies，但它的东西加起来。

KLOC可以成为项目所需基础设施的第一个指标。在这种情况下，我会包含注释和测试 - 即使注释行的运行成本远低于第二个项目中的正则表达式之一。

[edit] [对代码大小有类似看法的人] 1

Answer 7

我们只使用一行代码度量标准 - 函数包含足够的代码行，无需滚动屏幕即可读取。大于此的函数通常难以读取，即使它们具有非常低的循环复杂度。对于他的使用，我们会计算空白和评论。

在重构期间看到你已经删除了多少行代码也很高兴 - 在这里你只想计算实际的代码行数，这些空白空间无法提供可读性和评论没用的（无法自动化）。

最后是免责声明 - 智能地使用指标。充分利用度量标准有助于回答“代码的哪一部分将从重构中受益最多”或“最新签入的代码审查有多紧急？”这一问题。 - 一个具有50的圈复杂度的1000线函数是一个闪烁的霓虹灯，上面写着“现在重构我”。指标的错误用法是“程序员X的效率如何”或“我的软件有多复杂”。

Answer 8

摘自文章：How do you count your number of Lines Of Code (LOC) ?相对于工具NDepend，它计算.NET程序的逻辑numbers of lines of code。

您如何计算代码行数（LOC）？

你算方法签名声明吗？你只计算支架线？由于参数数量很多，当在多行上写入单个方法调用时，您是否计算了几行？你算'命名空间'和'使用命名空间'声明吗？你算上接口和抽象方法声明吗？在声明字段时，您是否计算字段分配？你算空白吗？

根据每个开发人员的编码风格，并根据语言选择（C＃，VB.NET ...），通过测量LOC可能会有显着差异。

显然，通过解析源文件来测量LOC看起来像一个复杂的主题。由于精明，存在一种简单的方法来精确测量所谓的逻辑LOC。逻辑LOC比物理LOC（从解析源文件推断出的LOC）有两个明显的优势：

编码样式不会干扰逻辑LOC。例如，LOC不会改变，因为由于参数数量很多，方法调用会在几行上生成。
逻辑LOC独立于语言。从使用不同语言编写的程序集中获得的值具有可比性，可以求和。

在.NET世界中，可以从PDB文件计算逻辑LOC，PDB文件是调试器用于将IL代码与源代码链接的文件。 NDepend工具以这种方式计算方法的逻辑LOC：它等于为PDB文件中的方法找到的序列点的数量。序列点用于标记IL代码中与原始源中的特定位置对应的点。更多关于序列点的信息。请注意，不考虑与C＃括号'{'和'}'对应的序列点。

显然，类型的LOC是其方法的LOC的总和，命名空间的LOC是其类型的LOC的总和，程序集的LOC是其命名空间的LOC和LOC的总和。应用程序是其程序集LOC的总和。以下是一些观察结果：

接口，抽象方法和枚举的LOC等于0.在计算LOC时，只考虑有效执行的具体代码。
命名空间，类型，字段和方法声明不被视为代码行，因为它们没有相应的序列点。
当C＃或VB.NET编译器面向内联实例字段初始化时，它会为每个实例构造函数生成一个序列点（相同的注释适用于内联静态字段初始化和静态构造函数）。
从匿名方法计算的LOC不会干扰其外部声明方法的LOC。
NbILInstructions和LOC（在C＃和VB.NET中）之间的总体比率通常在7左右。

LOC计数是否包括测试和评论？

8 个答案:

您如何计算代码行数（LOC）？