我应该保留错误的命名约定吗？
我目前正在开发一个网站，这个网站经过了天知道有多少开发者之手。我不喜欢它的一件事是数据库中的每个表都有前缀“tbl_”和每个字段“fld_”。
我已经开始开发一项新功能，但面临以下问题：我的新表是否应该继续使用旧约定？
我想我应该这样做，但我觉得这样做很愚蠢:)
I'm currently working on a site which went through god knows how many developers' hands. One of the things I don't like about it is the way every table in the database has the prefix "tbl_" and every field "fld_".
I've started work on a new feature and I'm faced with the following problem: should my new tables continue with the old convention, or not?
I guess I should, but I feel stupid doing it :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（12）
我会保持相同的约定。无论它是否不好，至少它会是一致的。对于下一个掌握代码的开发人员来说，一致性非常重要。
I would keep the same convention.. Regardless of if it's bad or not at least it would be consistent. And consistency will be very important to the next developer who gets ahold of the code.
作为一名承包商，我经常面临这个问题。这是我的 2 美分：
如果它没有坏，那么客户让我改变它就是浪费钱。除非我重写整个应用程序，否则我通常会遵循旧的（坏的）标准（至少这样，应用程序的一部分不会使用一种约定，而其他部分则使用不同的东西 - 这使得代码可以被其他人读取）开发商）。
Being a contractor, I am faced with this problem a lot. Here is my 2 cents:
If it isn't broken, then the client is wasting their money having me change that. Unless I am rewriting the entire app, I usually keep with the old (bad) standards (at least that way, you don't have part of the app with one convention and other parts using something different - this keeps the code readable by other developers).
你有两个选择。
稍后会有人查看此代码，并需要处理您创建的任何差异。这意味着您需要意识到其他人会受到此决定的影响。如果有时间就做正确的事，如果没有时间就做丑陋的事……但要保持一致。
You have two options.
Someone will be looking at this code later and will need to deal with any differences you create. That means you need to be aware that other people are affected by this decision. Do the right thing if you have time, do the ugly thing if you don't have the time... but keep it consistant.
如果它在整个应用程序中保持不变的样式，我将遵循命名约定，这将使下一个开发人员更容易。
If it a constant style throughout the application I would follow the naming convention it will make it much easier on the next developer.
我倾向于关注所涉及的规模。对我来说，不良命名约定的一致性比同一代码库或数据库中的多个不同命名约定更可取。
如果有几张桌子并且您可以安全地更改它们，我的感觉是进行更改。但是，任何规模的应用程序或仅进行错误修复的应用程序可能都不值得花费时间和精力。
I tend to look at the scale involved. The consistency of a bad naming convention, to me, is preferable over a multitude of different ones in the same codebase or database.
If there are a handful of tables and you can safely change them, my feeling is to make the change. But anything of scale or an application that you're only doing a bugfix on is likely not worth the time and effort involved.
选择哪条路线成本更低，无论是金钱还是资源。如果它不能节省你清理和重新耕地的钱，那就不要这样做。只要咬紧牙关，继续前进。
Go with which ever route costs less, in money and resources. If it's not going to save you money going through and re-tilling the ground, then don't. Just grit your teeth and move forward.
“如果它没有坏，就不要修理它”
"If it ain't broke, don't fix it"
我认为你应该更喜欢一致性并遵循已经使用的约定。
想想那些落后于你的可怜的开发人员，他们必须处理两种不同的命名约定（原来的命名约定和新的命名约定），而新开发人员都不喜欢这两种命名约定。
I think you should prefer consistency and follow the convention already being used.
Think of the poor developer(s) who come along behind you and have to deal with two different naming conventions (the original one and your new one), neither of which the new developers like.
欢迎来到维护世界。 ;)
谁敢说下一个在该网站工作的人不会鄙视您的做事方式？
Welcome to the world of maintenance. ;)
Who's to say that the next person who works on the site won't despise the way you did things?
任何命名约定都比没有/不一致的命名约定要好。
Any naming convention is better than no/inconsistent naming convention.
我说如果旧代码和新代码之间存在显着差异，则更改它。例如，如果旧的方式是一个可怕的死胡同，而新的方式是完全独立的，那么就继续并开始一个新的约定。
如果新材料在结构和语义上一致，那么在视觉上保持一致是件好事，但如果你正在做的事情与之前的事情完全不同，那么不同的东西看起来不同就更重要了。
I say change it iff there's a significant difference between the old code and the new code. For example, if the old way was a terribly dead-end and the new way is completely independent, then go ahead and start a new convention.
It's good to be visually consistent if the new material is structurally and semantically consistent, but if what you're doing is a clean break from what came before, then it's even more important that different things look different.
就像大家说的那样，请遵守不好的约定，因为您不是从头开始编写的。但是，如果有迫切需要，请使用“良好实践”（否则最终用户将受到负面影响）。例如，如果“不好的约定”使API用户使用装箱，则在很大程度上改变字符串和其他性能影响的值；不要增加问题！软件和 API 的最终目标不是让开发人员的生活更轻松；而是让开发人员的生活变得更轻松。但最终用户的。长期从事该行业的开发人员都高度意识到这一点，并且您想成为这些开发人员中的一员。
Like everyone said, stay with the bad convention since you are not writing it from scratch. However, use "good practice" if there is a compelling need for it (aka the end-user will be negatively affected otherwise). For example, if the "bad convention" makes the API users use boxing, change the value of strings and other performance-hit to a great degree; do not add to the problem! The end goal of software and API's is not to make the developers' life easier; but the end-user's. Developers that stay in the business long are highly aware of this and you want to be one of those developers.