几乎可以用成本和收益来分析任何事情，我认为这适用于此。
第一种选择的明显好处是，它可以在短期内最大程度地减少工作量，并通过重写工作代码来最大程度地减少破坏某些事物的机会。显而易见的代价是它将不一致性引入代码库。当您执行某项操作X时，它在代码的某些部分以一种方式完成，而在代码的不同部分以另一种方式完成。
对于第二种方法，您已经注意到了明显的好处：一致性。显而易见的代价是，您必须下定决心以可能几年前就已经放弃的方式工作，并且代码始终无法读取。
对于第三种方法，显而易见的成本就是必须要做很多工作。不太明显的代价是您可能会破坏正在运行的东西。如果（通常是）旧代码的测试不足以确保其继续正常运行，则这种情况尤其可能发生。显而易见的好处是（假设您成功完成了）您拥有了漂亮，闪亮的新代码。除了使用新的语言构造外，您还可以重构代码库，即使您仍按编写时所使用的语言使用该语言，它几乎总是会对其自身进行改进-添加新的结构来工作更轻松，这很可能是一个重大胜利。
不过，还有一个要点：目前看来，该模块在很长一段时间内维护最少（即使整个项目都得到维护）。这往往表明它编写得相当好并且相对没有错误-否则，在此期间可能需要进行更多的维护。
这就引出了另一个问题：您现在所做的更改的来源是什么？如果要修复一个总体上仍能很好满足其要求的模块中的小错误，这可能表明重构整个模块的时间和精力可能会浪费大量时间，而这需要有人去解决。再说一次，它们可能处于与您现在大致相同的位置，维护的代码不符合“现代”期望。
但是，也有可能需求发生了变化，并且您正在研究满足这些新需求的代码。在这种情况下，您的初次尝试实际上不会满足当前要求的机会很大。在需求再次稳定之前，还需要进行几轮修订的机会要大得多。这意味着您更有可能在近期内（相对）在此模块中进行重要的工作，并且更有可能在模块的其余部分进行更改，而不仅仅是在您所知的一个领域内进行更改。现在。在这种情况下，重构整个模块更有可能带来切实的近期收益，这些收益证明了额外工作的合理性。
如果需求已更改，则您可能还需要查看所涉及的更改类型以及导致更改的原因。例如，假设您正在修改Git，以将SHA-1的使用替换为SHA-256。这是要求的变化，但是范围是明确定义的并且非常狭窄。正确存储和使用SHA-256后，您就不太可能遇到影响其余代码库的其他更改。
在另一个方向上，即使开始时很小且离散，对用户界面的更改也有膨胀的趋势，因此，以“向该屏幕添加一个新复选框”开头的结果更像是：“更改此固定UI支持用户定义的模板，自定义字段，自定义配色方案等。”
对于前一个示例，最小化更改和一致性方面的错误可能最有意义。对于后者，完全重构更有可能获得回报。