我如何估算一行代码的寿命？

我正在尝试找出一种方法来分析开源项目中的代码寿命：即，特定代码行处于活动状态并使用了多长时间。

我当前的想法是，一行代码的生命周期从第一次提交时开始，到发生以下情况之一时结束：

• 它已被编辑或删除，
• 从构建中排除，
• 一段时间（例如一年）内不会维护其内部版本中的代码。

注意：为了澄清为什么将“编辑”视为“死亡”，已编辑的行将被视为“新一代”或代码行。同样，除非有简单的方法可以做到，否则就无法说明血统的长寿或祖先的后裔。

还有什么会决定一行代码的寿命？

Andy Ozment在2006年对OpenBSD提出了同样的问题：牛奶还是葡萄酒：软件安全性会随着年龄的增长而提高吗？

您也许可以从他的定义中学到东西。这也是一篇非常有趣的论文，也得出了一个有趣的结论，但尚未纳入软件管理知识中：

在7.5年的时间里，共发布了15个版本，OpenBSD中报告的140个漏洞中有62％是基础漏洞：研究开始时已存在于代码中。

这些基本漏洞的上半年花了两年半的时间才能报告。我们发现所研究的最终版本中的源代码中有61％是基础代码：与7.5年前发布的初始版本相比，它保持不变。因此，OpenBSD中基本漏洞的报告率很可能会继续极大地影响漏洞报告的总体率。

我们还发现了统计上显着的证据，表明在研究期间基本脆弱性报告的比率下降了。我们使用可靠性增长模型来估计发现了基础版本中的67.6％的漏洞。该模型对每天报告的预期基本漏洞数量的估计值，从研究开始时的0.051降低到了0.024。

我认为没有答案。它高度依赖项目。这些年来，有些更稳定，而有些则更不稳定/重构/发展。

而且，很难测量。编辑的行是否真的使用寿命结束了？只做表面上的更改，例如用制表符或空格重新格式化代码库，该怎么办？恕我直言，这不会算作更新的代码库，但会根据您的标准。

就是说，我认为很多LOC可以永远存在。

原因很简单：添加新代码比删除一些代码更容易。尤其是当系统复杂且多年来不断增长时。然后很快就会达到删除或更改非平凡代码的“风险”。它可能会引入错误，破坏兼容性，引入变化的蝴蝶效应……所以我认为，代码库越大，代码库越旧，LOC将保留的越多。

而且，只有优秀的程序员才倾向于清理代码库并减少行数。所有其他人往往会堆积LOC。到目前为止，后者取得了胜利。;）

删除或排除一行代码绝对是其生命周期即将结束的指示。

在进行编辑时，我会问这个问题：在编辑之后，此语句会产生不同的结果吗？

如果答案是肯定的，那么我会说先前的陈述不再可用，否则我仍将其视为先前陈述的延续。

更改结果的示例：

if ( a && b )

至：

if ( a || b )

延长使用寿命的示例：

foo.bar( baz );

至：

foo.prototype.bar.call( this, baz );