Coding style 在新作业中继承应用程序

在新工作中继承应用程序时，您是倾向于坚持最初的开发人员编码实践，还是开始应用您自己的实践

我在一家没有指导方针的小商店工作，总是想知道这里有什么规定。有些应用程序写得很好，但不遵循我使用的标准（变量名等），我不想“弄脏”它们。我发现我自己需要一点额外的时间来保持一致

其他人写得很差，看起来开发人员每次击键都在改变主意

附加思想 那我什么时候开始自己的项目呢？因此，现在我在混合中引入了一个新的编码标准：

好代码-但不是我的风格

错误的代码包含错误的实践和缺乏标准

我自己的标准

---

如果代码中有明显的标准，您应该坚持这些标准。如果没有，就开始介绍你自己的。

如果只有你，就去做吧。如果它是一个团队，特别是如果任何原始开发人员仍然在（或可能被邀请进行咨询），请尽可能保持现有的风格和实践。不要跟着他们走下老鼠洞——如果你认为他们在做傻事，就改变它，但如果这只是一种风格，就尽可能保持他们的风格

---

在我从事过的几项工作中，除了“如果您正在对现有文件/类进行更改，请使用现有的样式，即使是新代码。”

如果我继承了显然从未重构过的代码，我会借此机会强加一些我自己的结构

如果人们希望我为代码添加功能估算时间和成本，我需要非常熟悉它，并确保它符合我的标准

---

如果代码已经写得很好，那将是一件幸事，我不会弄乱它。但根据我的经验，这种情况并不经常发生。

出版一本遵循最佳实践的风格指南，并围绕遵循它建立共识。根据需要重构旧代码以维护它。

我认为这取决于“编码实践”的含义。如果你指的是代码格式化和命名约定之类的东西，我会亲自考虑“化妆品”，那么就坚持到底。如果你的意思是首先要编写最佳代码和正确编写代码，那么如果可能的话，可以回去解决问题，但至少要让你的新代码遵循最佳实践。

我和你站在同一条船上。从上一个家伙那里继承了一些应用程序的孤独开发者。我

---

我一直坚持他对现有项目的一致性标准，并使用我自己对新东西的偏好。

鉴于我继承的大多数应用程序都是由“牛仔程序员”破解的，他们甚至没有应用最基本的编码实践，我的观点有点偏颇

如果没有或存在明显错误和/或愚蠢的编码标准（例如，“所有变量的长度不得超过4个字符”，“每个数据库列都是varchar（255）null）”等），我建议引入编码标准。显然，如果你有一个团队，那么你需要就实施哪些实践达成一致意见，但如果你是一个独立开发人员，那么你有自由支配权，IMO你应该给混乱引入秩序。

• 如果代码有效，并且似乎有一个干净的格式。不要浪费时间改变风格
• 如果代码写得不好。当你有空闲时间，或者下次你在项目上工作时，一定要改变它
• 对于新项目，请按照您的方式执行，因为没有标准。和其他编写良好的程序一样，您的程序应该很容易维护

---

如果有公司标准，我会遵守

如果没有任何变化，而且变化很小，我会采用所使用的编码风格

如果有更大的改变要做，我不喜欢编码器的风格，我会使用我自己的。

---

如果现有的代码不好，我也会修改。

您是否有更好的机会用标准样式更新现有代码？可能不会。当你是新的代码，你将有最好的机会采取一些额外的时间，使非新的功能和非错误修复的变化。缺乏标准可能会让人沮丧，但您不太可能比第一次继承代码时有更好的标准化机会。

听起来我们谈论的是一种没有官方风格指南/最佳实践的情况。在这种情况下，正如肖恩所说，我会带头建立一些。但是如果可能，选择一个现有的、广泛使用的标准。它更有可能被接受，所有的参数都完成了，开箱即用的工具支持（编辑器、代码审查工具等）的几率大大增加

让其他人采用它通常是自下而上的最佳做法——根据新标准编写新代码，向其他人提及你已经这样做了，征求反馈。比试图获得批准和提前购买要容易得多

在现有的丑陋项目中，避免对现有模块进行大规模更改。首先，如果文件突然被重新插入，差异和版本控制将变得非常混乱

---

如果您正在处理的块非常糟糕以至于无法读取，我会进行初始签入以重新格式化它；接下来是实际的代码更改。

我会对代码应用相同的重构标准，就像它符合我的风格标准一样。也就是说，我会忽略风格，继续我的事业

如果遵循代码中的风格不是非常困难的话——关于命名约定，我会继续在新代码中使用它们

然而，我不会费心去尝试像“不应该使用制表符”、“每行应该缩进2个空格”这样的东西