在新作业中继承应用程序

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

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

如果你打算在不久的将来把它交给另一个开发人员(这个角色是暂时的),不要改变风格。

如果您要完全、独占、永久拥有该模块,请更改它,但请遵循以下规则:

一次一个变化。

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

立即根据您的喜好调整所有支架的位置,并提交更改。

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

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

不要在这上面花太多时间。

如果需要一两个小时以上,那就减少。

使提交描述清晰。

因此,在分析变更历史时,您可以快速忽略这些变更。

使用自动化工具

确保结果是一致和完整的,这样你就不必再惹麻烦了。

运行测试

仅仅因为你的改变不应该影响行为,并不意味着它们不会。(三重否定,哎哟!)

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

有人可能有一个他们想现在提交的更改,与你的更改合并会很痛苦。此外,你不想让任何人感到惊讶,在你之前告诉你的老板。

别再这样了

这是一次性的事情。

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

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

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

我注意到,大多数人认为他们之前的人都不知道如何编写代码。那么,无论谁来 他们 想同样的事情。有些事情是常识,但大多数事情只是个人喜好。

对于主要问题,即使用注释与不使用注释,更新代码可能会使使用更容易,也更容易让其他人使用。即便如此,你最好还是花时间在遇到代码时更新它,而不是开始一个庞大的项目来重构一切(在这个过程中引入新的问题)。

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

我认为这取决于你所说的“编码实践”是什么意思。如果你的意思是代码格式和命名约定,以及我个人认为“装饰性”的东西,那么就坚持现有的东西。如果你的意思是编码最佳提示和首先正确编写代码,那么如果可能的话,回去解决问题,但至少要让你的新代码遵循最佳实践。

鉴于我继承的大多数应用程序都是被“牛仔程序员”黑客攻击在一起的,他们甚至没有应用最基本的编码实践,我的观点有点偏颇。

如果没有编码标准,或者现有的编码标准明显错误和/或愚蠢(例如“所有变量的长度不得超过4个字符”,“每个数据库列都是varchar(255)null”等),我建议引入编码标准。显然,如果你有一个团队,那么你需要就实施什么实践达成一致,但如果你是一个独立开发人员,那么你就可以自由支配,在国际海事组织中,你应该为混乱引入秩序。

• 如果代码正常工作,并且似乎有一个干净的格式。不要浪费时间改变风格。
• 如果代码写得不好。当你有空闲时间,或者下次你处理这个项目时,一定要改变它。
• 对于新项目,按照你的方式去做,因为没有标准。和其他写得很好的程序一样,你的程序应该很容易维护。

组合通常比继承更受欢迎

P

如果只有你一个人,那就去做吧。如果是一个团队,特别是如果任何原始开发人员仍然在身边(或可能被请来咨询),尽可能多地保持现有的风格和做法。不要盲目追随他们——如果你认为他们在做愚蠢的事情,就改变它,但如果这只是一种风格上的事情,尽可能地保持他们的风格。

在我从事的几项工作中,我们没有关于编码风格的规则,除了“如果你要对现有的文件/类进行更改,即使是新代码,也要使用现有的风格。”

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

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

如果需要进行更大的更改,并且我不喜欢程序员的风格,我会使用我自己的风格。 如果现有的代码不好,我也会改变它。

你会有更好的机会用标准样式更新现有代码吗?可能不会。当你对代码不熟悉时,你将有最好的机会花一些额外的时间来进行非新功能和非bug修复更改。缺乏标准可能会令人沮丧,但与第一次继承代码时相比,你不太可能有更好的机会进行标准化。

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

让别人采用它通常是自下而上的最佳方式——根据新标准编写新代码,向别人提到你已经这样做了,并征求反馈。比提前获得批准和购买要容易得多。

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

如果你正在处理的块是 所以 如果不可读,我会先办理一次登机手续 只是 重新格式化;随后进行实际的代码更改。

如果代码符合我的风格标准,我会对代码应用相同的重构标准。也就是说,我会忽略这种风格,继续做我的生意。

如果遵循代码中的风格不是非常困难——关于命名约定,我会继续将其用于新代码。

然而,我不会费心去遵循“不应该使用制表符”、“每行应该缩进2个空格”等内容。现在有很多编辑器,你可以在需要的时候“美化”代码。

G-Man

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

• 如果你是一个项目的短期顾问,你应该坚持现状。
• 如果你在很长一段时间。试着把糟糕的代码重构成你自己的方案。
• 如果你在短时间内工作,但你正在处理一个孤立的模块,那么使用你自己的方案。

简短的回答是,“这取决于。”以下是我认为在决定是否保留旧风格时很重要的几个因素:

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

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

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

当你开始自己的项目时,投入你所知道的最好的标准。

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

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

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