我应该保持不好的命名约定吗?

我会遵守同样的惯例。。不管它是坏是坏,至少它是一致的。对于下一个掌握代码的开发人员来说,一致性是非常重要的。

如果它没有坏,那么客户让我换它是在浪费他们的钱。除非我重写整个应用程序,否则我通常会遵循旧的(不好的)标准(至少这样,你不会有一部分应用程序使用一种约定,而其他部分使用不同的东西——这会让其他开发人员能够阅读代码)。

1. 将所有不好的命名约定更改为新的命名约定。

稍后将有人查看此代码,并且需要处理您创建的任何差异。这意味着你需要意识到其他人会受到这个决定的影响。如果你有时间做正确的事,如果你没有时间做丑陋的事。。。但要保持一致。

如果它在整个应用程序中保持不变的风格,我将遵循命名约定,这将使下一个开发人员更容易使用它。

我倾向于看涉及的规模。对我来说,一个糟糕的命名约定的一致性比同一个代码库或数据库中的许多不同的命名约定更可取。

如果有几张桌子,你可以放心地更换它们,我的感觉是进行更改。但是,任何规模的应用程序或只是进行错误修复的应用程序都可能不值得花费时间和精力。

想想那些可怜的开发人员,他们跟在你后面,不得不处理两种不同的命名约定(原始的和新的),新开发人员都不喜欢。

欢迎来到维护世界。;)

任何命名约定都比没有/不一致的命名约定好。

如果旧代码和新代码之间存在显著差异,我就说改变它。例如,如果旧的方式是一条死胡同,而新的方式是完全独立的,那么就开始新的惯例吧。

如果新材料在结构和语义上都是一致的,那么保持视觉上的一致性是很好的,但是如果你所做的与之前的完全不同,那么更重要的是不同的东西看起来是不同的。

就像每个人都说的,坚持坏习惯,因为你不是从头开始写的。但是,如果有迫切的需求,请使用“良好实践”(否则最终用户将受到负面影响)。例如,如果“坏约定”使得API用户使用装箱,那么字符串的值和其他性能的影响会在很大程度上改变;不要增加问题!软件和API的最终目标不是让开发人员的生活更轻松;但是最终用户的。长期从事业务的开发人员非常清楚这一点,您希望成为这些开发人员中的一员。