编码标准的演变，您如何处理它们？

在现有代码库的项目中，您如何处理编码标准/样式指南中的演变？假设您的团队中的某人在编程语言中发现了一种更好的对象实例化方法。并不是说旧的方法是不好的或越野的，而是新的方法不再那么冗长，而感觉却更加优雅。所有团队成员都非常喜欢。您会更改所有现有代码吗？

假设您的代码库大约有500.000多行代码。您是否仍要更改所有现有代码？还是只让新代码遵守新标准？基本上失去一致性？

您如何处理项目编码标准的演变？

存在编码标准以提高团队的生产力。从理论上讲，它们使代码更易于理解，更改和测试。在实践中，它们可能会创建大量的元工作。团队不断地重写现有代码，以寻求最正确，最优雅的解决方案。不幸的是，在每个人都参与，充满激情并且热衷于做正确的事情的团队中，元工作问题似乎更加严重。

作为一个从一个项目转移到另一个项目的顾问，我发现具有严格的编码标准的优秀学科对项目成功的贡献远不如对结果感兴趣的优秀开发人员。不一致的编码样式对出色的开发人员来说是一个很小的麻烦。无论有无一致性，它们都能高效地工作。当然，如果他们遇到不一致的代码，他们会询问当前标准并坚持下去。但是，他们不会坚持将项目中的每一行代码都更新为当前标准。他们不坚持，因为他们已经看到了最佳实践的来龙去脉。今天正确的做事方式与明天正确的做事方式不同。如果是这样，您的编码标准就不会发展。因此，如果做某事的正确方法随时间而改变，那么我们对“正确”的定义可能会被打破。

这并不是说标准无关紧要。请记住，标准的目标是生产力。如果您不能保证重写新标准可以长期收回成本，那么请不要在上面浪费时间。在新的或重构的代码中证明新标准的合理性要容易得多。优雅很酷，但与结果不同。

我们所做的是代码库的演进（而不是革命），我们将在以下情况下使用更新的标准：

• 编写新代码
• 代码被重构
• 错误已修复
• 新部分添加到现有类中

您的代码库必须保持一致，这一点很重要，因此，如果所做的更改可能会在“旧”样式代码与“新”样式代码之间造成混淆，那么最好将编码标准的更新保留给下一个项目。

首先，我不会在（必须的）编码指南中包括这样的“最佳实践”。他们可能在附录中被提及，例如，作为一个例子，你如何可以做一些事情，但不是它应该做的方式。

也就是说，有两种情况需要考虑更改编码标准：

1. 即使旧代码和新代码混合在一起而不更新旧代码，更改也不会影响可读性。
   这些更改可以立即添加到编码标准中，并且必须对所有新的和修改的代码都有效。在时间允许的情况下以及在该区域进行更改时，应逐渐对旧代码进行调整。
   我实际上遇到的这种更改的一个示例是在每个文件开头的版权声明中的更改。
2. 如果新旧代码混合使用，则会降低可读性。
   这些更改应该一次性应用到整个代码库，或者如果确实需要，则应重新考虑。
   此类更改的一个示例是缩进或括号位置的更改。

这实际上取决于您要创建的产品类型：

• 对于内部编写的商业应用程序，并且您正在部署给客户，您的主要目标应该是收入。只要旧代码没有错误，那么新的编码标准已经发展就没关系，您应该集中精力为产品添加新功能并产生收入。一定要使新的编码标准适应新的编码，但是更改所有现有的编码将浪费时间。
• 如果你正在开发一个开源的产品，或产品在多个企业（甚至你的客户）会看到和源工作，那么代码的可读性变得多少更重要，在这种情况下，明智的决定应取决于准确进行从长远来看，需要更改多少代码以及会有什么好处。尽管我们都喜欢漂亮的代码，但实际上，对于一家处理封闭源代码的商业公司而言，不断采用新标准意味着从长远来看，您将失去收入。

就个人而言，我会选择保留旧代码，并从新做起就遵循新标准。更具体地说，我不会在old.c中使用双重标准。但是，如果要创建new.c，它可以使用更新的精炼语法：)