我目前正在开发一个通过上帝了解有多少开发人员的网站。我不喜欢的一件事是数据库中的每个表都有前缀“tbl_”和每个字段“fld _”的方式。
我已经开始研究一项新功能了，我遇到了以下问题：我的新表是否应继续使用旧约？
我想我应该，但我觉得这样做很愚蠢：）
答案 0 :(得分：28)
我会保持相同的惯例..无论它是否坏或至少它都是一致的。对于获得代码的下一位开发人员而言，一致性将非常重要。
答案 1 :(得分：8)
作为承包商，我经常遇到这个问题。这是我的2美分：
如果它没有被破坏，那么客户正在浪费他们的钱让我改变它。除非我重写整个应用程序，否则我通常会遵循旧的（坏的）标准（至少这样，你没有使用一个约定的应用程序的一部分和使用不同的东西的其他部分 - 这使得代码可以被其他人读取开发人员）。
答案 2 :(得分：3)
您有两种选择。
有人会在稍后查看此代码，并且需要处理您创建的任何差异。这意味着你需要意识到其他人会受到这个决定的影响。如果你有时间做正确的事，如果你没有时间做那件丑事......但要保持一致。
答案 3 :(得分：2)
如果它在整个应用程序中是一个恒定的样式，我将遵循命名约定，它将使下一个开发人员更容易。
答案 4 :(得分：2)
我倾向于考虑所涉及的规模。对我来说，错误命名约定的一致性优于同一代码库或数据库中的众多不同命名约定。
如果有一些桌子你可以安全地改变它们，我的感觉就是做出改变。但任何规模或应用程序，你只是做错误修复可能不值得花时间和精力。
答案 5 :(得分：1)
在资金和资源方面，减少哪条路线的成本更低。如果它不会为你节省资金并重新耕种，那就不要了。只要咬紧牙关往前走。
答案 6 :(得分：1)
“如果没有破损，请不要修复它”
答案 7 :(得分：1)
我认为您应该更喜欢一致性并遵循已经使用的惯例。
想想那些跟在你身后的穷人，必须处理两种不同的命名惯例（原始的和新的），新开发者都不喜欢。
答案 8 :(得分：1)
欢迎来到维护世界。 ;）
谁能说下一个在网站上工作的人不会鄙视你做事的方式？
答案 9 :(得分：1)
任何命名约定都优于无/不一致的命名约定。
答案 10 :(得分：0)
我说如果旧代码和新代码之间存在显着差异，请更改它。例如，如果旧的方式是一个非常死胡同，而新的方式是完全独立的，那么继续开始一个新的约定。
如果新材料在结构和语义上是一致的，那么在视觉上是一致的很好，但是如果你正在做的是与之前的一致，那么不同的东西看起来不同就更重要了。
答案 11 :(得分：0)
就像每个人都说的那样，因为你不是从头开始编写，所以要坚持不好的约定。但是，如果有迫切的需要，请使用“良好实践”（否则最终用户将受到负面影响）。例如，如果“不良约定”使API用户使用装箱，则在很大程度上改变弦乐的值和其他表现。不要添加问题！软件和API的最终目标不是让开发人员的生活更轻松;但最终用户的。长期留在业务中的开发人员非常了解这一点，并且您希望成为这些开发人员之一。