6

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

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

其他人写得非常糟糕，看起来开发人员每次击键都会改变主意......

额外的想法

当我开始自己的项目时呢？所以现在我引入了一个新的编码标准：

  1. 好的代码——但不是我的风格
  2. 具有不良实践和缺乏标准的不良代码
  3. 我自己的标准
4

17 回答 17

21

如果代码中有明显的标准，你应该遵守它们。如果没有，请开始介绍自己的。

于 2009-01-28T15:14:26.827 回答
10

如果有多个开发人员在同一模块上工作，请不要更改样式。

如果您将在不久的将来将其交给其他开发人员（此角色是临时的），请不要更改样式。

如果您要获得模块的完整、独占、永久所有权，请更改它，但请遵循以下规则：

一次改变一个。

立即根据您的喜好修复所有缩进，并提交该更改。

立即根据您的喜好修复所有支撑位置，并提交该更改。

立即根据您的喜好修复所有其他格式，并提交该更改。

立即根据您的喜好修复所有命名，并提交该更改。

不要花很多时间在上面。

如果需要超过一两个小时，则减少。

使提交描述清晰。

因此，您可以在分析更改历史记录时快速忽略这些更改。

使用自动化工具

确保结果一致且完整，这样您就不必再搞砸了。

运行你的测试

仅仅因为您的更改不应该影响行为并不意味着它们不会。（三重否定，哎哟！）

确保每个人都知道你在做什么

有人可能有一个他们想要现在提交的更改，并且与您的更改合并会很痛苦。此外，您不希望任何人感到惊讶并在您这样做之前告诉您的老板。

不要再这样做了

这是一次性的事情。

于 2009-01-28T16:13:44.397 回答
3

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

于 2009-01-28T15:18:31.403 回答
3

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

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

于 2009-01-28T15:24:12.283 回答
3

我注意到大多数人认为在他们之前的任何人都不知道如何编写代码。然后，无论谁跟在他们后面，都会有同样的想法。有些事情是常识，但大多数事情只是个人喜好。

对于主要问题，即使用注释与不使用注释，更新代码可能会更容易使用，也更容易让其他人使用。即使这样，您最好还是花时间在遇到代码时对其进行更新，而不是着手进行一个巨大的项目来重构所有内容（在此过程中引入新问题）。

对于缩进、行距、变量名、单行 ifs 与多行 ifs 等问题，现实情况是您的编码风格可能和您认为的一样糟糕。

于 2009-01-28T16:20:18.673 回答
2

我认为这取决于您所说的“编码实践”是什么意思。如果您的意思是诸如代码格式和命名约定之类的东西以及我个人认为“装饰性”的东西，那么请坚持使用已有的东西。如果您的意思是首先编写最佳实践和正确编写代码之类的事情，那么请尽可能返回并解决问题，但至少要让您的新代码遵循最佳实践。

于 2009-01-28T15:20:04.320 回答
2

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

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

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

组合通常优于继承

:-P

于 2009-01-28T17:21:47.943 回答
1

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

在我从事的几项工作中，除了“如果您要对现有文件/类进行更改，请使用现有风格，即使是新代码”，我们对编码风格没有任何规定。

于 2009-01-28T15:17:27.350 回答
1

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

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

如果代码已经写得很好，那将是我不会乱来的福气。但根据我的经验，这种情况并不经常发生。

于 2009-01-28T15:17:52.483 回答
1

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

如果没有并且变化很小，我采用使用的编码风格。

如果要进行较大的更改并且我不喜欢编码器的样式，我将使用自己的。如果现有代码不好，我也会改变它。

于 2009-01-28T15:29:23.363 回答
1

您是否有更好的机会使用标准样式更新现有代码？可能不是。当您对代码不熟悉时，您将有最好的机会花一些额外的时间来进行非新功能和非错误修复的更改。缺乏标准可能令人沮丧，但您不太可能有比第一次继承代码时更好的机会进行标准化。

于 2009-01-28T15:30:17.980 回答
1

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

让其他人采用它通常会自下而上发挥最佳效果——根据新标准编写新代码，向其他人提及你已经这样做，征求反馈意见。比试图提前获得批准和支持要容易得多。

在现有的丑陋项目中，避免对现有模块进行大规模更改。一方面，如果文件突然重新缩进，差异和版本控制会变得相当混乱。

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

于 2009-01-28T15:32:07.103 回答
1

如果代码符合我的风格标准，我会应用相同的重构标准。也就是说，我会忽略这种风格，继续我的事业。

如果遵循代码中的风格不是很困难 - 关于命名约定，我会继续将它们用于新代码。

但是，我不会费心尝试遵循诸如“不应使用制表符”、“每行应缩进 2 个空格”等内容。有很多编辑器可以在需要时“漂亮”代码这几天。

G人

于 2009-01-28T15:34:23.917 回答
1

我认为这在很大程度上取决于具体情况。

  • 如果你是一个项目的短期顾问，你应该坚持原来的样子。
  • 如果你开很长时间。尝试将不良代码重构为您自己的方案。
  • 如果您的工作时间很短，但您正在处理一个独立的模块，那么请使用您自己的方案。
于 2009-01-28T15:54:27.383 回答
1

简短的回答是，“这取决于。” 在确定是否保留旧样式时，我认为以下几个因素很重要：

1) 变更范围。如果它接近于对应用程序的完全重写，那么如果你有一个你认为适合你的新标准，那么引入一个新标准可能更有意义。

2) 未来变化的可能性。这会一次又一次地改变吗？如果是这样，那么尽早花一些时间最终可能是值得的。这确实需要一些判断和预测未来，但在某些情况下，很容易看出对于一些相当复杂的系统会一次又一次地发生变化。

3) 与完全自主开发的应用程序相比，有多少代码是在第三方代码库上定制的，例如，公司对其业务流程的 Oracle 产品的特定定制。这里的影响是，当发布新版本并请求升级时，由于定制了如此多的内容，可能会对哪些问题造成多大的痛苦。

在开始您自己的项目时，请输入您所知道的最佳标准。

于 2009-01-28T16:36:59.513 回答