如果有的话，“代码行数”是一个有用的指标？
有人声称代码最大的敌人就是它的大小，我倾向于同意。 然而你每天都会听到类似的话
- 我在一天之内写了无数的代码。
- 我拥有x行代码。
- Windows是x百万行代码。
问：什么时候“＃代码”有用？
ps：请注意，当这样的陈述发出时，语气是“越多越好”。
我会说，这是当你删除代码，使项目运行更好。
说你删除了“X行”是令人印象深刻的。 而且比添加代码行更有帮助。
我很惊讶没有人提到迪杰斯特拉的名言，所以这里是：
我今天的观点是，如果我们要计算代码的行数，我们不应该把它们看作是“产生的线条”，而是把它看作是“花费的线条”：现在的传统智慧是愚蠢的，总帐。
引用来自一篇名为“ 关于真正教计算科学的残酷 ”的文章。
这是一个可怕的指标，但是正如其他人所指出的那样，它给了你一个系统总体复杂性的（非常）粗略的概念。 如果你比较两个项目，A和B，A是10000行代码，B是2万，这并不能告诉你很多 – 项目B可能过于冗长，或者A可能被超级压缩。
另一方面，如果一个项目是10,000行代码，另一个是100万行，那么第二个项目总的来说要复杂得多。
这个度量标准的问题在于用来评估某个项目的生产力或贡献水平。 如果程序员“X”写入2倍于程序员“Y”的行数，他可能会或可能不会贡献更多 – 也许“Y”正在努力解决一个更难的问题…
当吹牛给朋友。
装载行式打印机时非常有用，以便您知道要打印的代码列表将消耗多less页面。 ;）
有一个特别的例子，我发现它是非常宝贵的。 当你在面试时，他们告诉你，你的工作的一部分将是维护现有的C / Perl / Java /等。 传统项目。 询问采访者有多lessKLOC（大约）参与了遗留项目会给你一个更好的想法，你是否想要他们的工作。
至less，不是为了进步：
“通过编码来衡量编程进度就像衡量飞机build筑进度的重量。” – 比尔盖茨
像大多数指标一样，没有语境就意味着很less。 所以简短的回答是：从来没有（除了行式打印机，这很有趣！谁打印出这些日子？）
一个例子：
想象一下，你正在进行unit testing和重构遗留代码。 它以50,000行代码（50 KLOC）和1,000个可certificate的错误（unit testing失败）开始。 每50行代码的比率是1K / 50KLOC = 1个错误。 显然这是可怕的代码！
现在，经过几次迭代，通过示例性的重构，已经将已知的 bug减less了一半（并且未知的bug比最有可能的更多），代码量减less了五倍。 现在这个比率是每20行代码500/10000 = 1个错误。 这显然更糟！
根据您想要制作的印象，可以将其展示为以下一项或多项：
- 减less50％的错误
- less了五倍的代码
- 减less80％的代码
- 错误代码比率恶化了60％
所有这些都是真实的（假设我没有搞错math），他们都在总结这种重构努力必须取得的巨大进步。
答：当你可以谈论负面的代码行。 如下所示：“我今天删除了40多行代码，程序仍然和以前一样运行。”
有许多不同的软件度量标准 。 代码行是最常用的，也是最容易理解的。
我很惊讶代码行度量与其他度量标准的相关性。 而不是购买一个可以计算圈复杂度的工具来发现代码的味道，我只是寻找多行的方法，而且它们往往也有很高的复杂度。
使用代码行的一个很好的例子是度量：每行代码中的错误。 它可以让你直觉地感受到你应该在项目中find多less错误。 在我的组织中，我们通常每1000行代码有20个左右的错误。 这意味着如果我们准备发行一个拥有100,000行代码的产品，并且我们的bug数据库显示我们已经发现了50个bug，那么我们应该做更多的testing。 如果我们每1000行代码中有20个错误，那么我们可能正在接近我们通常所处的质量。
一个不好的例子就是衡量开发者的生产力。 如果您通过代码行来衡量开发人员的工作效率，那么人们往往会使用更多的线路来减less交付。
这是衡量生产力和复杂性的指标。 像所有指标一样，需要谨慎评估。 一个单一的指标通常不足以提供完整的答案。
IE，一个500线的程序并不像5000线那么复杂。 现在，您必须提出其他问题才能更好地了解该计划…但现在您已经有了一个指标。
我同意在项目中使用代码行数是衡量复杂性的一种方法。
这当然不是复杂性的唯一标准。 例如，debugging100行混淆的Perl脚本与使用注释模板debugging5000行Java项目有很大的不同。
但是不看源代码，你通常会认为更多的代码行比较复杂，就像你可能认为10MB的源代码包比15kb的源代码包更复杂一样。
这在许多方面是有用的。
我不记得确切的＃但微软有一个networking演员，谈论每X代码平均有一些错误。 你可以采取这种说法，并用它来为几件事情提供一个基准。
- 代码审查人员如何做他们的工作。
- 通过比较两个员工的bug比率来判断两个员工的技能水平。
另一件我们看到的是，为什么这么多的线？ 通常情况下，当一个新的程序员陷入困境时，他们只会复制和粘贴代码块，而不是创build函数和封装。
我认为我一天写了x行代码是一个可怕的措施。 它不考虑问题的难度，语言写作，等等。
在我看来，对于任何给定的项目来说，我可以从头脑中引用多less行代码是有限制的。 一般程序员的极限可能非常相似。 因此，如果你知道你的项目有200万行代码，你的程序员可以期望能够理解一个bug是否与他们熟知的5K代码行有关，那么你就知道你需要雇用400你的代码库的程序员可以很好地从某人的记忆中被覆盖。
这也会让你三思而后行，你的代码基础太快了，可能会让你考虑重构它，使它更容易理解。
注意我编了这些数字。
让我想起这件事：
这封信是很长的，因为我没有闲暇把它缩短。
– 贝斯Pascal
为了解释大约25年前我读的一句话，
“使用代码行作为衡量标准的问题是衡量解决scheme的复杂性，而不是问题的复杂性”。
我相信这句话是从David Parnas在“ACM杂志”上的一篇文章中得到的。
这是吓人/令人印象深刻的一个很好的指标。 这就是关于它的问题，以及我在这三个例子中看到的背景。
代码行对于了解代码文件是否变得太大时非常有用。 嗯…这个文件现在是5000行代码。 也许我应该重构这个。
当你必须预定你需要订购的打卡数量。
我写了2篇博客文章，详细说明了代码行（LoC）的优缺点：
你如何计算你的代码行数（LOC）？ ：这个想法是解释说你需要计算逻辑代码行数而不是物理计数。 要做到这一点，你可以使用像NDepend这样的工具。
为什么计算代码行数（LOC）很有用？ ：这个想法是，永远不应该使用LoC来衡量生产力，但更多的是testing覆盖率估计和软件截止期估计。
软件工程研究所的软件社区过程成熟度简介：1998年年底更新（我找不到一个不幸的链接）讨论了大约800个软件开发团队（或者也许是商店）的调查。 平均缺陷密度是每1000LOC12个缺陷。
如果您的应用程序有0个缺陷（实际上不存在，但我们假设），并写了1000个LOC，平均而言，您可以假设您刚刚向系统中引入了12个缺陷。 如果QA发现1或2个缺陷，那么他们需要做更多的testing，因为可能有10多个缺陷。
当你重构一个代码库并且可以显示你删除了代码行，并且所有的回归testing仍然通过。
代码行实际上并不是那么有用，如果它被pipe理者用作度量标准，它会导致程序员进行大量的重构来提高他们的分数。 另外，不好的algorithm不能被整齐的短algorithm所取代，因为这会导致对你的负面LOC计数。 说实话，对于一家使用LOC / d作为生产力指标的公司来说，不要这么做，因为pipe理层对于软件开发显然没有任何线索，因此从第一天开始就一直处于后退阶段。
在比赛中。
当编码器不知道你正在计算代码行，所以没有理由故意添加冗余代码来游戏系统。 而且当团队中的每个人都有相似的编码风格时（所以每行都有一个已知的平均“价值”），而且只有当你没有更好的方法时。
查看维基百科的定义： http : //en.wikipedia.org/wiki/Source_lines_of_code
SLOC ='源代码行'
实际上，在我工作的这些指标中有相当多的时间。 计算SLOC也有不同的方法。
从维基百科的文章：
有两种主要types的SLOC度量：物理SLOC和逻辑SLOC。
另一个很好的资源： http : //www.dwheeler.com/sloc/
正如大多数人已经指出的那样，这可能是一个模棱两可的指标，特别是如果您比较使用不同语言编码的人。
Lisp！5,000行= C = 5,000行
当它与缺陷的数量相关时，这是一个非常有用的想法。 “缺陷”给你一个代码质量的措施。 软件的“缺陷”越less越好; 几乎不可能消除所有的缺陷。 在很多情况下，单一的缺陷可能是有害的，致命的。
但是，似乎没有缺陷的软件存在。
在确定努力水平（LOE）时。 如果你正在制定一个提案，并且你将有大致的同一个工程师在这个新项目上工作，那么你可能能够确定需要多less工程师多久。
当指出为什么变化将持续这么久。
“Windows有700万行代码，需要一段时间才能testing出所有的依赖关系……”
