测量代码行 (LoC)，包括相对权重答案

【问题标题】：Measure Lines of Code (LoC) including relative weight测量代码行 (LoC)，包括相对权重
【发布时间】：2013-09-24 07:56:50
【问题描述】：

我必须衡量一个项目和一个版本中有多少代码行（在两个标签之间创建）。我可以做到这一点，这对我来说没有问题。

我的问题是关于我必须“附加”到组成项目的文件的重量。我必须以相对的方式权衡文件，以便我们最终得到一个加权标记。例如：如果我有 CPP 项目，我相信我必须对 cpp 文件赋予不同的权重； h 文件和文本文件，因为在每种文件类型上投入的时间完全不同。

此外，我可能会考虑为添加的行、删除的行和更改的行提供不同的标记，因为有时更改现有行（而不是添加新行）需要更多时间。不过我还不确定。

你知道我在哪里可以找到关于这方面的好读物吗？我的问题很笼统——我还想了解 Java、C# 和任何代码语言。

谢谢

【问题讨论】：

对不起，我知道你不想听到这个......但是用代码行测量任何东西与用“完成”相对于“是否能够现在飞？” - 我见过数百行可以重构为“正确完成”的 10 行。
我真的不会将 LoC 视为一个有意义的指标。例如，将广泛使用 Linq 的代码与不使用 Linq 的代码进行比较。 LoC 是 1980 年代的风格指标。 stackoverflow.com/questions/184071/…
LoC 是一个很好的衡量项目努力的指标。使用 LINQ 编写代码的人比在汇编中编写等效代码的人投入的精力要少得多。当然是努力！= 生产力也不是努力！= 质量。
@PiotrKolaczkowski 好吧，使用array[0] = 0; array[1] = 0; array[2] = 0; 等初始化大型数组可能并不需要太多努力，每行一个语句;)
任何 LoC 指标都默认假设程序员保持行长合理并编写干净的代码。很明显，任何代码总是可以做得更长。

【解决方案1】：

您可能对 COCOMO II 模型感兴趣。但是，请注意，根据行数来判断代码可能会产生误导——不要用它来补偿你的开发人员，否则他们会开始编写非常冗长的代码，你很快就会破产;)

【讨论】：

谢谢。我发现了这个：en.wikipedia.org/wiki/COCOMO。你确定是指重量？我找不到这样的
COCOMO II 使用许多不同的权重来表示团队技能、项目难度等。不过，我不知道它是否使用依赖于编程语言的权重。然而，这是一个非常有争议的话题——有些人会说 Python 代码比等效的 C++ 代码短 10 倍，有些人会说它只有 2 倍，唯一确定的是：这取决于项目和程序员的技能。