你遵循原始程序员的命名约定吗？
如果您从某人那里接手一个项目来进行简单的更新，您会遵循他们的命名约定吗？ 我刚刚收到一个项目，其中以前的程序员到处都使用匈牙利表示法。 我们的核心产品有一个命名标准，但多年来我们有很多人做定制报告，并做他们想做的事。
不过，我没有时间更改代码中已有的所有变量名称。
我倾向于为了可读性而继续他们的命名约定。
If you take over a project from someone to do simple updates do you follow their naming convention? I just received a project where the previous programmer used Hungarian Notation everywhere. Our core product has a naming standard, but we've had a lot of people do custom reporting over the years and do whatever they felt like.
I do not have time to change all of the variable names already in the code though.
I'm inclined for readablity just to continue with their naming convention.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（20）
就我个人而言，每当我接手一个具有不同变量命名方案的项目时，我倾向于保留前一个程序员使用的相同方案。 我做的唯一不同的是，对于我添加的任何新变量，我在变量名称前加了一个下划线。 这样我就可以快速查看我的变量和代码，而无需进入源代码历史记录并比较版本。 但是，当涉及到我继承一些不可读的代码或注释时，我通常会仔细检查它们并尽我所能清理它们，而无需重新编写整个内容（已经到了这个地步）。 组织是拥有可扩展代码的关键！
Personally whenever I take over a project that has a different variable naming scheme I tend to keep the same scheme that was being used by the previous programmer. The only thing I do different is for any new variables I add, I put an underscore before the variable name. This way I can quickly see my variables and my code without having to go into the source history and comparing versions. But when it comes to me inheriting simply unreadable code or comments I will usually go through them and clean them up as best I can without re-writing the whole thing (It has come to that). Organization is key to having extensible code!
如果我可以阅读代码，我（尝试）采用相同的约定
如果它无论如何都不可读，我需要重构并因此改变它（取决于它的样子）相当大
if I can read the code, I (try) to take the same conventions
if it's not readable anyway I need to refactor and thus changing it (depending on what its like) considerable
依靠。 如果我正在构建一个新应用程序并使用垃圾变量命名从旧应用程序中窃取代码，那么一旦将其放入我的应用程序中，我就会进行重构。
Depends. If I'm building a new app and stealing the code from a legacy app with crap variable naming, I'll refactor once I get it into my app.
是的..
有一点比走进一个具有两种截然不同风格的应用程序更令人沮丧。 我最近从事的一个项目有两种不同的文件操作方式、两种不同的屏幕实现方式、两种不同的基本结构。 第二位编码员甚至将新功能作为从主代码调用的 dll 的一部分。 维护是一场噩梦，我必须学习两种范式，并希望当我在一个部分时我正在使用正确的范式。
Yes..
There is litte that's more frustrating then walking into an application that has two drasticly different styles. One project I reciently worked on had two different ways of manipulating files, two different ways to implement screens, two different fundimental structures. The second coder even went so far as to make the new features part of a dll that gets called from the main code. Maintence was nightmarish and I had to learn both paradigms and hope when I was in one section I was working with the right one.
在罗马做到入乡随俗。
（索引变量名称除外，例如“iArrayIndex++”。停止纵容这种白痴行为。）
When in Rome do as the Romans do.
(Except for index variables names, e.g. "iArrayIndex++". Stop condoning that idiocy.)
我认为修复错误就像外科手术一样。 进去，尽可能少地打扰，修复它，出去，尽可能少地留下你在那里的痕迹。
I think of making a bug fix as a surgical procedure. Get in, disturb as little as possible, fix it, get out, leave as little trace of your being there as possible.
我确实这样做，但不幸的是，在我之前的几位开发人员没有遵守这条规则，所以我有几种命名约定可供选择。
但有时我们有时间把事情搞清楚，所以最终，事情会变得美好而干净。
I do, but unfortunately, there where several developers before me that did not live to this rule, so I have several naming conventions to choose from.
But sometimes we get the time to set things straight so in the end, it will be nice and clean.
如果代码已经具有一致的风格，包括命名，我会尝试遵循它。 如果以前的程序员不一致，那么我可以随意应用公司标准，或者如果没有任何公司标准，我的个人标准。
无论哪种情况，我都会尝试通过用注释来标记我所做的更改。 我知道当今的 CVS 系统通常无法做到这一点，但我仍然更愿意这样做。
If the code already has a consistent style, including naming, I try to follow it. If previous programmers were not consistent, then I feel free to apply the company standard, or my personal standards if there is not any company standard.
In either case I try to mark the changes I have made by framing them with comments. I know with todays CVS systems this is often not done, but I still prefer to do it.
不幸的是，大多数时候答案是肯定的。 大多数时候，代码不遵循良好的约定，因此很难遵循先例。 但为了可读性，有时有必要顺其自然。
但是，如果应用程序足够小，我可以重构大量现有代码以“闻起来”更好，那么我就会这样做。 或者，如果这是更大的重写的一部分，我也将开始使用当前的编码标准进行编码。 但通常情况并非如此。
Unfortunately, most of the time the answer is yes. Most of the time, the code does not follow good conventions so it's hard to follow the precedent. But for readability, it's sometimes necessary to go with the flow.
However, if it's a small enough of an application that I can refactor a lot of the existing code to "smell" better, then I'll do so. Or, if this is part of a larger re-write, I'll also begin coding with the current coding standards. But this is not usually the case.
如果现有应用程序中有标准，我认为最好遵循它。 如果没有标准（制表符和空格混合，到处都是大括号……哦，太可怕了），那么我会做我认为最好的事情，通常通过格式化工具（如 Vim）运行现有代码。 如果有一致的风格，我将始终保留现有代码的大写风格等。
我对此规则的一个例外是，除非有人用枪指着我的头，否则我不会使用匈牙利符号。 我不会花时间重命名现有的东西，但我添加的任何新东西都不会带有任何匈牙利疣。
If there's a standard in the existing app, I think it's best to follow it. If there is no standard (tabs and spaces mixed, braces everywhere... oh the horror), then I do what I feel is best and generally run the existing code through a formatting tool (like Vim). I'll always keep the capitalization style, etc of the existing code if there is a coherent style.
My one exception to this rule is that I will not use hungarian notation unless someone has a gun to my head. I won't take the time to rename existing stuff, but anything I add new isn't going to have any hungarian warts on it.
是的，我愿意。 它使在您之后继承它的人更容易跟随。 如果代码确实难以理解，我会尝试稍微清理一下代码，使其更具可读性。
Yes, I do. It makes it easier to follow by the people who inherit it after you. I do try and clean up the code a little to make it more readable if it's really difficult to understand.
我同意建议保留作者编写的代码就可以只要该代码内部一致。如果代码由于不一致而难以遵循，那么您对未来的维护者负有责任（可能是你）以使其更清楚。
如果您花费 40 个小时来弄清楚一个函数的用途，因为它使用了命名不当的变量等，那么您应该为了清晰起见而重构/重命名/添加注释/做任何适合情况的事情。
也就是说，如果唯一的问题是作者使用的大部分一致的风格与公司标准或您习惯的风格不同，我认为您正在浪费时间重命名所有内容。 此外，如果原作者仍然可以回答问题，那么您可能会失去专业知识来源，因为他不再识别该代码。
I agree suggest that leaving the code as the author wrote it is fine as long as that code is internally consistent. If the code is difficult to follow because of inconsistency, you have a responsibility to the future maintainer (probably you) to make it clearer.
If you spend 40 hours figuring out what a function does because it uses poorly named variables, etc., you should refactor/rename for clarity/add commentary/do whatever is appropriate for the situation.
That said, if the only issue is that the mostly consistent style that the author used is different from the company standard or what you're used to, I think you're wasting your time renaming everything. Also, you may loose a source of expertise if the original author is still available for questions because he won't recognize the code anymore.
如果您不将所有现有代码更改为您的标准，那么我会说只要您更改这些文件，就坚持原始约定。 在同一个文件中混合两种风格的代码会破坏一致的代码风格所带来的任何好处，并且下一个人必须不断地问自己“谁编写了这个函数，它将被称为什么 - FooBar() 或 fooBar( ）？”
当您导入第三方库时，这种事情会变得更加棘手 - 您不想重写它们，但它们的代码风格可能与您的不匹配。 因此最终，您将得到几种不同的命名约定，并且最好在“我们的代码”和“他们的代码”之间划清界限。
If you're not changing all the existing code to your standard, then I'd say stick with the original conventions as long as you're changing those files. Mixing two styles of code in the same file is destroying any benefit that a consistent code style would have, and the next guy would have to constantly ask himself "who wrote this function, what's it going to be called - FooBar() or fooBar()?"
This kind of thing gets even trickier when you're importing 3rd party libraries - you don't want to rewrite them, but their code style might not match yours. So in the end, you'll end up with several different naming conventions, and it's best to draw clear lines between "our code" and "their code".
通常，仅仅为了符合风格指南而对代码库进行大规模更改只是引入新错误的一种方式，几乎没有什么附加值。
这意味着您应该：
更新您正在处理的代码，使其在处理时符合指南。
使用代码中的约定来帮助将来的维护工作。
我推荐 2.，但是匈牙利表示法让我眼睛流血:p。
Often, making a wholesale change to a codebase just to conform with the style guide is just a way to introduce new bugs with little added value.
This means that either you should:
Update the code you're working on to conform to the guideline as you work on it.
Use the conventions in the code to aide future maintenance efforts.
I'd recommend 2., but Hungarian Notation makes my eyes bleed :p.
如果您正在维护其他人编写的代码，并且其他人将在您之后维护这些代码，那么您应该对所有相关人员负责，不要进行无端的更改。 当他们进入源代码控制系统查看您更改的内容时，他们应该看到解决您正在处理的问题所需的内容，而不是一百万个差异，因为您进行了一堆全局搜索并替换或重新格式化了代码适合您最喜欢的牙套搭配惯例。
当然，如果原始代码真的很糟糕，那么所有的赌注都将落空。
If you are maintaining code that others wrote and that other people are going to maintain after you, you owe it to everybody involved not to make gratuitous changes. When they go into the source code control system to see what you changed, they should see what was necessary to fix the problem you were working on, and not a million diffs because you did a bunch of global searches and replaces or reformatted the code to fit your favourite brace matching convention.
Of course, if the original code really sucks, all bets are off.
一般来说，是的，在这种情况下，我会优先考虑约定和可读性而不是标准。 没有人喜欢这个答案，但为了保持代码的长期可维护性，这是正确的做法。
当一个好的程序员阅读代码时，他应该能够解析变量名称并在他的头脑中跟踪几个变量名称——只要它们一致，至少在源文件中。 但如果你打破了这种一致性，它可能会迫使阅读代码的程序员遭受一些认知失调，这将使跟踪变得更加困难。 这不是杀手——优秀的程序员会通过它，但他们会咒骂你的名字，并可能将你发布在 TheDailyWTF。
Generally, yes, I'd go for convention and readability over standards in this scenario. No one likes that answer, but it's the right thing to do to keep the code maintainable long-term.
When a good programmer's reading code, he should be able to parse the variable names and keep track of several in his head -- as long as their consistent, at least within the source file. But if you break that consistency, it will likely force the programmer reading the code to suffer some cognitive dissonance, which would then make it a bit harder to keep track of. It's not a killer -- good programmers will get through it, but they'll curse your name and probably post you on TheDailyWTF.
我当然会继续使用相同的命名约定，因为它将使代码保持一致（即使它始终丑陋）并且比混合变量命名约定更具可读性。 人类的大脑似乎非常擅长模式识别，你不想通过无缘无故地打破这种模式来给大脑扔一个曲线球。
也就是说，我对匈牙利表示法一窍不通，但如果这就是你必须使用的......
I certainly would continue to use the same naming convention, as it'll keep the code consistent (even if it is consistently ugly) and more readable than mixing variable naming conventions. Human brains seem to be rather good at pattern recognition and you don't really want to throw the brain a curveball by gratuitously breaking said pattern.
That said, I'm anything but a few of Hungarian Notation but if that's what you've got to work with...
如果文件或项目已经使用一致的风格编写，那么您应该尝试遵循该风格，即使它与您现有的风格冲突/矛盾。 代码风格的主要目标之一是一致性，因此，如果您在已经一致（在其内部）的代码中引入不同的风格，您就会失去这种一致性。
如果代码写得不好并且需要一定程度的清理才能理解它，那么清理样式就成为一个更相关的选项，但只有在绝对必要的情况下才应该这样做（特别是在没有单元测试的情况下），当你运行引入意想不到的重大变化的可能性。
If the file or project is already written using a consistent style then you should try to follow that style, even if it conflicts/contradicts your existing style. One of the main goals of a code style is consistency, so if you introduce a different style in to code that is already consistent (within itself) you loose that consistency.
If the code is poorly written and requires some level of cleanup in order to understand it then cleaning up the style becomes a more relevant option, but you should only do so if absolutely necessary (especially if there are no unit tests) as you run the possiblity of introducing unexpected breaking changes.
绝对没错。 我认为最好不要遵循原始程序员的命名约定的一种情况是，原始程序员（或此后修改代码的后续开发人员）未能遵循任何一致的命名约定。
Absolutely, yes. The one case where I don't believe it's preferable to follow the original programmer's naming convention is when the original programmer (or subsequent devs who've modified the code since then) failed to follow any consistent naming convention.
是的。 我实际上在标准文档中写了这个。 我在当前的公司创建了：
现有代码取代所有其他标准和实践（无论它们是行业范围的标准还是本文档中的标准）。 在大多数情况下，您应该改变代码以匹配同一文件中的现有代码，原因有两个：
Yes. I actually wrote this up in a standards doc. I created at my current company:
Existing code supersedes all other standards and practices (whether they are industry-wide standards or those found in this document). In most cases, you should chameleon your code to match the existing code in the same files, for two reasons: