在软件开发过程中主动使用“代码行”（LOC）指标？

Question

代码库大小与软件系统的复杂性有很大关系（尺寸越大，维护和扩展的成本就越高）。映射代码库大小的方法是简单的“代码行（LOC）”指标（另请参阅blog-entry 'implications of codebase-size'）。

我想知道你们当中有多少人使用这个指标作为回顾性创建意识的一部分（用于删除未使用的功能或死代码）。我认为创建更多代码行意味着维护和扩展更复杂的意识可能是有价值的。

我没有将LOC视为细粒度指标（在方法或功能级别上），而是在子组件或完整产品级别上。

Answer 1

我发现它有点无用。例如，某些类型的功能 - 用户输入处理，无论如何都会有点长篇大论。我宁愿使用某种形式的复杂度指标。当然，您可以将两者和/或任何其他指标结合起来。你需要的只是一个很好的工具 - 我使用Source Monitor（除了满意的用户之外我没有任何关系）这是免费的，可以为你做LOC和复杂度指标。

我在编写代码时使用SM来让我注意到过于复杂的方法。然后我回去看看他们。大概有一半时间我说，好吧，那需要那么复杂。我真正喜欢的是（免费）工具和SM一样好，但它也支持某种标记列表，其中说“忽略方法X，Y和Z - 它们需要复杂” 。但我想这可能很危险，这就是为什么我到目前为止还没有向SM的作者提出这个功能。

Answer 2

我认为当LOC 减少时可以用它来奖励团队（假设他们仍在生产有价值的软件和可读代码......）。

Answer 3

并非总是如此。虽然通常优选具有低LOC，但这并不意味着代码不那么复杂。事实上，它通常更加如此。经过优化以获得最少循环次数的代码可能完全无法读取，即使是一周之后编写它的人也是如此。

作为最近项目的一个例子，想象一下从PNG文件中设置单个颜色值（RGBa）。你可以通过多种方式实现这一目标，最紧凑的是使用位移的1行。这比另一种方法更难以读取和维护，例如使用位域，这将采用结构定义和更多行。

它还取决于进行LOC计算的工具。它是否只将单个符号作为代码考虑（Ex：{和}在C风格的语言中）？这肯定不会使它更复杂，但确实使它更具可读性。

只是我的两分钱。

Answer 4

LOC很容易获得并在一个非常简单的项目中提供合理的信息。我在新项目中的第一步始终是计算LOC。