我正在寻找真实的数据和经验，请不要过于主观地接受这个：
在寻找其他内容时，我happened on an interesting statement，部分内容如下：
[...]全国平均值为9,000 每年的代码行数 人。[...]
我写了很多代码，但不是全职。当我回顾过去一年的项目时，我做了一个（非常）粗略的计算（只计算代码行，没有评论或白线），我来到大约19.000一年，这使它成为一个项目。如果我可以自动化部分内容，我可以及时和省钱地扣除利润。
为了估算大型项目的省时，我需要平均值。一年中，人们用C＃（或其他选择的语言）编写了多少代码行？而且，看看你自己的情况，你会认为你的手写代码可以（部分）自动化并获得什么收益？
答案 0 :(得分：5)
18000平均每天约36行代码。
每天只有36行代码，问题是什么？问题是调试和重写代码。
没有你可以做的自动编码会加快你的速度 - 事实上，任何你可以自动化的东西都不应该被编码，因为如果你在代码中自动输入某些模式，那么它应该被考虑在内。 / p>
您可以节省时间，更加小心您的编码方式。通过QA更快地完成项目 - 使用更明确，类型安全的语言编写代码并更清晰地编写代码。
同时尽可能地驱动代码数据并进行全面考虑，尽管它会减少您发布的LOC，但它会让每个人的生活更轻松，项目的运行速度更快。
不要自动化代码输入 - 如果可以的话，你做错了！
另一种思考方式 - 您创建的每一行代码都必须进行调试和维护。当你可以创建完全因素化的代码时，为什么你想要想办法给每个人更多的工作（完全因素代码的输入不能自动化 - 几乎按照定义）。
答案 1 :(得分：3)
这是Mythical Man Month中谈到的指标类型。以人日/月/年为单位估算项目，或将代码行计为生产力度量表，可以保证报告不准确。
答案 2 :(得分：3)
首先，编写的代码行与实际生产率无关。至少在我看来，如果你想测量和/或估算生产率，功能点是一个更有效的衡量标准。其次，当指标在很大范围内变化时，平均值通常意味着很小。在这种情况下，几何平均值通常意味着超过算术平均值，但没有（至少）关于方差/标准差的东西，它仍然没有多大意义。
我还注意到，有些相当复杂的模型经过了大量的研究，甚至可以根据实际项目进行衡量，以至少得出一些结论，即他们的结果与现实相关。例如，COCOMO II模型通常会产生比每单位时间使用代码行更好的结果。至少有一个free online implementation（编辑：查看它，现在允许基于LoC或基于功能点的建模）。还有一个工具，如SoftStar和Function Point Modeler），它们将类似COCOMO的模型与功能点结合起来，以使得（至少对我而言）看起来是相当可靠的结果。
答案 3 :(得分：1)
我认为LOC的比率很大程度上取决于项目中的technical debt。
我有一个27KLOC的项目（SQL）（加上4K以上的支持）。在这个代码上工作了7个多月，我在项目中增加了3K净新LOC，大约14KLOC仅用于一次性测试（测试以隔离异常，而不是单元测试）。
根据你的测量方法，我写29KLOC /年（（3K + 14K）/ 7个月* 12个月），但每年只生产5KLOC（3K / 7个月* 12个月）。
将代码（27KLOC）视为债务，我们的代码每月一次性生成7％（2KLOC），或每年88％（24KLOC）。
假设我可以继续使用整个29KLOC /年，并且假设维护代码的成本保持在88％/年，我的个人项目限制是33K行代码。除此之外，我将花费我所有的时间来支付我的技术债务利息，编写一次性代码，并产生净零LOC。
幸运的是，最后一个3KLOC是重构，这应该会降低我的利率。
答案 4 :(得分：-2)
实际上，这是一个相当BS的问题。即使SLOC信徒也会向您承认SLOC生产力估算仅在类似环境中有效。它不仅因编程语言而异，而且因行业，开发环境，应用程序等而异。
尽管SLOC数字是值得的，但它只是在同一个开发团队中从事类似的项目。