如果我的LOC /天比率过高，是否应该打扰我？[关闭]

我目前正在从事一个独立项目，因此我没有进行整个人工测试或外部代码审查的全部精力–但是，我在当前代码中看不到任何困难的错误（我已将其修复，因为我看到了这些错误） ，而且在大多数情况下，它们只是错误的字段名称等，您需要在一两分钟之内解决的问题），并且在实现任何功能之前，我会先进行测试，然后再进行推送。最近，我的LOC号码每天大约为400（根据记录，它是C＃），我不仅在实现新系统，还重写了我已经写的东西并修复了一些错误。

我应该打扰吗？这是否是我需要停止并查看我到目前为止一直在写的所有代码并对其进行重构的标志？

LOC可能是滥用最严重的指标之一，因此可能是更无用的代码质量度量之一，也是对编程工作的更无用度量。

是的，这对我来说是一个大胆的声明，不，我无法指出您要证明我观点的研究。但是，我可以用来之不易的经验来说明，当您开始担心编写了多少代码时，您可能会担心错误的问题。

首先，您需要问自己要测量或证明的内容是什么，以及该证明仅仅是出于兴趣，还是为了支持更广泛的质量改进，以及您需要在何处使用此信息从团队中获得支持/ management做一些事情。

我倾向于使用LOC的一件事是进行完整性检查。如果我发现自己编写了很多代码，那么我会对每个方法或每个类的LOC而不是整个LOC更加感兴趣。如果您对代码的分解程度感到有些强迫症，那么这些度量可能是您需要进一步重构的指标。非常大的类可能需要重构为几个较小的类，长的多行方法可能需要分解为几个方法和其他类，甚至可能指示某些重复可以删除。注意，我在那里多次使用“可能”一词。

现实情况是，LOC仅提供可能的指示符，而不能真正保证您的代码可能需要更改。要问的真正问题是代码是否按照要求和预期运行。如果是这样，那么下一个问题是您是否能够轻松维护代码，以及现在或将来是否有时间对工作代码进行更改以减少将来的维护开销。

通常，许多代码意味着您以后需要维护的代码更多，但是有时即使结构合理的代码也可以扩展到数百行代码，是的，您有时会发现自己一天要编写数百行代码。但是经验告诉我，如果我每天要维持数百行新代码的输出，通常会冒着很大一部分代码被不适当地从其他地方剪切和粘贴的风险，并且这本身可能表明存在问题。复制和维护，但这又不能保证，因此我倾向于根据手头任务的完成方式来依靠我的经验和直觉告诉我。

避免您的问题恕我直言所带来的困境的最佳方法是忘记LOC，并始终重构。首先编写您的代码测试，实施失败，重构以通过，然后查看在那里可能重构的内容，然后改进代码。您将离开该任务，知道您已经仔细检查了您的工作，并且您不必担心将来会再次猜测自己。实际上，如果您使用我所描述的测试优先的方法，那么对已完成代码的任何LOC /天度量值实际上都意味着您已写入了3-5倍的度量值，而这种努力被正在进行的重构成功地隐藏了努力。

一点也不-几天来您正在修复一个很难发现的错误，只更改了一行。否则，您将添加新代码并编写数千行。

每日LOC不会告诉您任何信息，只是当天的任务可以用400行代码来完成。

其中一些答案没有抓住重点，您不是将LOC用作生产率的度量标准（如果您当时就不会担心生产效率太高），那么您实际上所做的就是担心代码质量，因为代码是敌人，这是一件值得担心的好事情。

不幸的是，了解代码质量的唯一方法是代码审查，因为您是一个人的团队，即使您确实停止审查代码（并且您确实不想停止，对吗？）自己的代码不会像同行审查您的代码那样透露太多信息。我建议尝试让其他人查看至少您的某些代码，以便您可以判断您每天的400 LOC是否正在乱码。即使是对一日代码的独立审查也将在这里有所帮助

您不应该为每天生产的LOC数量而烦恼。

但是您应该打扰：

• 如果您的代码未经测试（例如，如果您没有单元测试）
• 如果您在添加新功能或更改实现的功能时遇到麻烦（这意味着您的重构不合适）
• 如果您的经验不多，并且您的代码没有经过审查（双眼可能会发现问题）

LOC是生产力的“官方”衡量标准，但是对其价值的争论可能很长（ORM可能在3分钟内生成50,000行代码，但是，如果数据库设计错误，那么所有这些代码都可能进入垃圾箱）。

我建议您通过跟踪完成的任务百分比，时间与计划完成的任务百分比来衡量进度。这才是最重要的。客户为能够为LOC提供业务价值的工作代码付费。

有关LOC的一些参考

• 反对：LOC-大多数无意义的措施

• 在某种程度上中性：Wiki-LOC

• 专业版（我不同意其中的大部分，但您可以看一下）：规模和代码行不经济

您还在测量重复代码的数量吗？

如果高输出是因为您的代码中包含大量复制和粘贴，那么您应该担心。

原因：如果您的复制粘贴源中有错误，修复复制粘贴的所有用法很困难且容易出错

如果您相信漂亮的功能代码，那么那应该是您唯一的措施

“它在流动吗？看起来很漂亮吗？”