C 跟随原作者'；什么是编码风格？即使它很可怕/懒惰/让你的眼睛流血？

当对一个非常古老的、显然不再维护的开源或公共领域项目做出贡献时，是否建议遵循原始作者的编码风格，即使它很糟糕

---

更重要的是，有没有什么原因让你想遵循原作者的编码风格，而不是对其进行大幅度的清理？

如果你知道它没有维护，并且你正在对它进行更改，那么我怀疑你将成为未来的实际所有者/维护者

---

因此，也就是说，我会给原作者/维护者发电子邮件，看看他们对格式或样式更改的看法，然后继续大炮射击。

如果你不提交修补程序，那么就不提交。通过代码过滤器运行，并以你喜欢的样式自动格式化代码，然后离开。

如果连维护都没有，你为什么还要担心呢

---

我会用我自己喜欢的风格来写，并清理所有我必须使用的代码。我经常在工作中这样做，甚至…

遵循原始的编码风格。保持一致性要好得多，即使这对你来说并不漂亮

---

如果您决定清理编码样式，请将其与任何其他更改分开进行。不要因为样式的改变而使源代码管理差异变得杂乱无章。进行一次（或多次）签入，您所做的唯一事情就是更改代码样式。不要将真实的更改与无意义的更改混为一谈，这样在查看源代码管理提交时就不可能找到相关的更改。

好吧，我想说，如果您只是在某个函数中做了一个小的修改，那么使用坏样式可能会更清楚

---

如果创建新方法、类、属性等，请使用清晰、高效的样式。您可以在这些部分的开头添加注释，以便其他人能够理解发生了什么。您甚至可以在顶部添加一个简短的注释，解释您是何时开始编写代码的，以及您使用的是不同的样式等等。

如果检查源代码管理，您可能希望不使用它，因为所有样式更改都会使与以前版本的比较变得不可能

如果确实要更改样式，请在进行任何其他更改之前使用基线代码进行更改，然后将其签入

然后检查并更改编码。这样，从您接管的那一刻起，跟踪您的更改就更容易了

---

我个人认为，除非你做出重大改变，否则我不会使用这种风格。

见鬼，不！看在上帝的份上，不管你做什么都不要让事情变得更糟

如果您要添加自己的代码，请以自己的方式添加。这至少会使代码库的一部分易于维护和理解。如果您正在对现有代码进行较小的更新，那么您可能希望遵循这种风格

---

我也在同一条船上，我必须维护一个古老的、关键业务的、基于Access 2的系统，这是一个风格完全混乱的系统。

如果问题是：当你重建你的家时，你是否应该保持同样的劣质工艺

如果你在浴室修理一块破损的墙砖，那么就不值得重新铺整面墙，因为他们没有使用正确的干墙

当你重新装修厨房的时候，你可能会修正房间的水管，或者把坏掉的地板弄直。那是因为它让你的其他工作变得更容易。这就是它的全部内容，它给你带来了什么样的好处，而不是给你/你的客户带来的成本

---

你不会因为灯需要新灯泡而重新布线。

如果你按照公司定义的标准（甚至只是团队定义的标准）编码，而你正在使用的代码与标准不匹配（或者太旧以至于与当前标准不匹配），如果你要做重大的改变，那么一定要清理代码。（如其他人所述，对基线代码执行此操作，并将其签入。然后再次签出，并进行您必须进行的更改，以修复错误、添加功能等）。

如其他人所述，确保将任何样式修改签入到版本控制系统中，与功能修改分开

然而，我的建议是大胆地清理你认为合适的代码；“让营地比你发现的更干净”。俗气，但真实；）

---

只要确保您准备好捍卫您的更改；）

+1-我唯一反对这个建议的时候是，如果原始代码样式很糟糕，因为它不一致。+1用于分离代码更改提交和样式更改提交+1.谈论混淆分歧：这是一个巨大的问题。我也看到过在“代码重新格式化”之后引入的bug，例如，当人们删除了引起问题的{}时。