每个人都说他们可以击败“神话人物月”中的“每个开发人员每天 10 行”，而开始一个项目，我通常可以在一天内完成几百行。
但是在我以前的雇主那里，所有的开发人员都非常敏锐，但这是一个大型项目，超过一百万行代码，认证要求非常繁重，并且与其他数百万行项目的接口。在某些时候，出于好奇，我在我的团队的交付产品中绘制了代码行（不包括我们开发的工具），果然，逐渐地，每个开发人员每天净添加大约 12 行代码。不计算更改、测试代码或开发人员并非每天都在处理实际项目代码这一事实。
其他人怎么样？你面临什么样的要求（我想这是一个因素）？
在我当前的一个项目中，在某些模块中，我很自豪能够为代码库贡献负数的行数。识别哪些代码区域增加了不必要的复杂性并且可以通过更清晰的设计来简化是一项有用的技能。
当然，有些问题本质上是复杂的，需要复杂的解决方案，但在大多数大型项目中，需求定义不明确或不断变化的区域往往具有过于复杂的解决方案，每行问题的数量更多。
鉴于要解决的问题，我更喜欢减少行数的解决方案。当然，在小项目开始时，我每天可以生成十多行代码，但我往往不会考虑我写了多少代码，只考虑它做了什么以及它做得如何。我当然不会以每天击败十条线为目标，也不会认为这样做是一种成就。
我喜欢这句话：
如果我们想计算代码行数，我们不应该将它们视为“产生的行数”，而是“花费的行数”。- Edsger Dijkstra
有时您通过删除代码而不是添加代码所做的贡献更多
我认为添加的行数很大程度上取决于项目的状态，添加到新项目的速度将远远高于启动项目的速度。
两者之间的工作是不同的——在一个大型项目中，您通常花费大部分时间来确定各部分之间的关系，而实际更改/添加的时间很少。而在一个新项目中 - 你主要写......直到它足够大并且速率降低。
你应该停止使用这个指标，它在大多数情况下是没有意义的。内聚、耦合和复杂性是比代码行更重要的指标。
其他人怎么样？
我是我们公司唯一的全职开发人员，在过去 7 年中编写了 500,000 行 OCaml 和 F# 代码，相当于每天大约 200 行代码。然而，绝大多数代码是教程示例，由数百个独立项目组成，每个项目几百行。此外，OCaml 和 F# 之间有很多重复。我们不维护任何大于 50kLOC 的内部代码库。
除了开发和维护我们自己的软件外，在过去的 7 年中，我还为许多行业客户提供过咨询服务。对于第一个客户，我在 3 个月内编写了 2,000 行 OCaml，即每天 20 行代码。对于下一个客户端，我们四个人编写了一个编译器，该编译器在 6 个月内生成了数百万行 C/C++/Python/Java/OCaml 代码以及文档，即每个开发人员每天 2,000 行代码。对于另一个客户，我在 6 个月内将 50kLOC 的 C++ 替换为 6kLOC 的 F#，即每天 -352 行代码。对于另一个客户，我正在用 F# 重写 15kLOC 的 OCaml，它的大小相同，因此每天 0 行代码。
对于我们当前的客户，我将在 1 年内将 1,600,000 行 C++ 和 Mathematica 代码替换为约 160kLOC 的 F#（通过编写定制编译器），这将是每天 -6,000 行代码。这将是我迄今为止最成功的项目，并将每年为我们的客户节省数百万美元的持续成本。我认为每个人都应该以每天编写 -6,000 行代码为目标。
没有真正检查我的“The Mythical Man-Month”副本（每个阅读此书的人都应该真的有一份现成的副本），其中有一章 Brooks 通过书写的行数来看待生产力。对他来说，有趣的一点不是每天实际编写的行数，而是在汇编程序和 PL/I 中它似乎大致相同（我认为这是使用的高级语言）。
Brooks 并不打算抛出某种任意的生产力数字，但他是根据实际项目的数据工作的，据我所知，他们可能平均每天 12 行。
他确实指出，生产力可能会有所不同。他说编译器的难度是应用程序的三倍，而操作系统的难度是编译器的三倍。（他似乎喜欢使用三的乘数来区分类别。）
我不知道他是否理解程序员生产力之间的个体差异（尽管在一个数量级的论点中，他确实假设了七倍的差异），但正如我们所知，卓越的生产力不仅仅是写更多的问题代码，还要编写正确的代码来完成这项工作。
还有环境问题。Brooks 推测了一些关于什么会使开发人员更快或更慢。像许多人一样，他质疑当前的时尚（使用分时系统进行交互式调试）是否比旧方法（使用整台机器进行两小时拍摄仔细预先计划）更好。
鉴于此，我认为他提出的任何实际生产力数字都是无用的。这本书的持续价值在于人们坚持不学习的原则和更普遍的教训。（嘿，如果每个人都学会了它们，这本书将只具有历史意义，就像弗洛伊德的所有论点一样，即存在类似潜意识的东西。）
每天很容易获得几百行代码。但是尝试每天获得几百行高质量的代码，这并不容易。最重要的是调试和每天很少或没有新行的日子，平均值会很快下降。我花了数周时间调试困难的问题，答案是 1 或 2 行代码。
意识到谈论物理代码行毫无意义会更好。物理代码行 (LoC) 的数量非常依赖于编码风格，以至于它可以从一个开发人员到另一个开发人员变化一个数量级。
在 .NET 世界中，有一种方便的方法来计算 LoC。序列点。序列点是一个调试单元，它是放置断点时以深红色突出显示的代码部分。使用序列点，我们可以谈论逻辑 LoC，并且可以在各种 .NET 语言之间比较该指标。大多数 .NET 工具都支持逻辑 LoC 代码度量，包括 VisualStudio 代码度量、NDepend 或 NCover。
例如，这是一个 8 LoC 方法（不考虑开始和结束括号序列点）：
必须长期计算 LoC 的产生。有些日子你会吐出超过 200 个 LoC，有些日子你会花费 8 个小时来修复一个错误，甚至不添加一个 LoC。有些日子你会清理死代码并删除 LoC，有些日子你会花所有时间重构现有代码，而不是在总数中添加任何新的 LoC。
就个人而言，我仅在以下情况下才将单个 LoC 计入我自己的生产力得分：
在这种情况下，我在过去 5 年中为 .NET 开发人员编写 NDepend 工具的个人得分是平均每天 80 个物理 LoC，而不会以任何方式牺牲代码质量。节奏是持续的，我认为它不会很快减少。总而言之，NDepend 是一个 C# 代码库，目前重量约为 115K 物理 LoC
对于那些讨厌计算 LoC 的人（我在这里的评论中看到了很多），我证明一旦经过充分校准，计算 LoC 是一个很好的估计工具。在对我的特定开发环境中实现的数十个功能进行编码和测量之后，我可以精确估计 LoC 中任何 TODO 功能的大小，以及我将其交付到生产环境所需的时间。
没有银弹这种东西。
像这样的单一指标本身是没有用的。
例如，我有自己的类库。目前，以下统计数据属实：
总行数：252.682
代码行数：127.323
评论数：99.538
空行数：25.821
假设我根本不写任何注释，也就是 127.323 行代码。以你的比例，这个代码库将需要我大约 10610 天的时间来编写。那是29年。
我当然没有花 29 年时间编写该代码，因为它全是 C#，而且 C# 出现的时间也不长。
现在，您可以争辩说代码不是那么好，因为显然我必须超过您每天 12 行的指标，是的，我会同意这一点，但如果我要将时间线缩短到1.0发布的时候（我直到2.0发布才开始真正做），也就是2002-02-13，大约2600天，平均一天48行代码。
所有这些代码行都好吗？哎呀，不。但是每天只写 12 行代码？
哎呀，不。
一切都取决于。
你可以让一个顶尖的程序员每天写几千行代码，一个中等程序员每天写几百行代码，质量是一样的。
是的，会有错误。
你想要的总数就是余额。更改的代码量、发现的错误数量、代码的复杂性以及修复这些错误的难度。
Steve McConnell 在他的“软件估计”一书中给出了一个有趣的统计数据（p62 表 5.2）他区分了项目类型（航空电子、商业、电信等）和项目大小 10 kLOC、100 kLOC、250 kLOC。在 LOC/StaffMonth 中给出了每个组合的数字。EG Avionic：200、50、40 Intranet 系统（内部）：4000、800、600 嵌入式系统：300、70、60
这意味着：例如。对于 Avionic 250-kLOC 项目，有 40（LOC/月）/22（天/月）== <2LOC/天！
我认为这来自瀑布式开发时代，项目的实际开发阶段可能只占项目总时间的 20-30%。将总代码行数除以整个项目时间，您将获得大约 10 行/天。除以编码周期，您将更接近人们引用的内容。
经过大约 150 人年的努力，我们的代码库约为 2.2MLoC。这使得在项目的整个生命周期中，每个开发人员每天大约需要75行 c++ 或 c#。
我认为项目规模和所涉及的开发人员数量是其中的重要因素。在我的职业生涯中，我的成绩远高于此，但我一直都是独自工作，所以与其他程序员一起工作不会有任何损失。
好的规划、好的设计和好的程序员。你把所有的东西加在一起，你不会花 30 分钟写一行。是的，所有项目都需要你停下来计划、思考、讨论、测试和调试，但是每家公司每天需要两条线来让俄罗斯方块工作......
最重要的是，如果你以每小时 2 条线的速度为我工作，你最好给我买很多咖啡和按摩我的脚，这样你就不会被解雇。
有人怀疑，当一切都是用 C 语言编写的 sys 应用程序时，这种长期存在的经理糖果是创造出来的，因为如果没有别的，这个神奇的数字会根据应用程序的语言、规模和性质而发生数量级的变化。然后你必须打折评论和属性。最终谁在乎编写的代码行数？当你达到 10K 行时，你应该完成吗？100K？如此随意。
没用的。