【发布时间】：2010-09-21 23:56:24
【问题描述】：
如果您从某人那里接手一个项目来进行简单的更新，您是否遵循他们的命名约定？我刚收到一个项目，以前的程序员到处使用匈牙利符号。我们的核心产品有一个命名标准，但多年来我们已经让很多人进行自定义报告，并随心所欲。
不过，我没有时间更改代码中已有的所有变量名。
我倾向于继续他们的命名约定以保持可读性。
【问题讨论】：
标签： variables naming-conventions hungarian-notation
【发布时间】：2010-09-21 23:56:24
【问题描述】：
是的，我愿意。它使继承它的人更容易跟随你。如果真的很难理解，我会尝试稍微清理一下代码以使其更具可读性。
【讨论】：
-
这也是 Kernighan 和 Pike 在“编程实践”中推荐的，出于同样的原因 - 持续清晰和可维护性。
-
而且也是“常识”推荐的;-)。
-
有趣的是，我们的职业中极度缺乏这种“常识” :)
我同意建议保留作者编写的代码，只要该代码在内部保持一致即可。如果由于不一致而难以遵循代码，您有责任向未来的维护者（可能是你）让它更清楚。
如果您花费 40 小时来弄清楚一个函数的作用，因为它使用了命名不当的变量等，您应该为了清晰起见重构/重命名/添加评论/做任何适合这种情况的事情。
也就是说，如果唯一的问题是作者使用的最一致的风格与公司标准或您习惯的风格不同，我认为您正在浪费时间重命名所有内容。此外，如果原作者仍然可以回答问题，您可能会失去专业知识来源，因为他将不再识别代码。
【讨论】：
-
+1，我从小就是个童子军，他们教我们离开去的地方比去的地方要好。
-
+1 给 Sam 的常识，而不是盲目地遵循规则。 +5 罗伯特承认黄金法则也适用于软件。 :-)
如果您没有将所有现有代码更改为您的标准，那么只要您更改这些文件，我会说坚持原来的约定。在同一个文件中混合两种风格的代码正在破坏一致的代码风格所带来的任何好处，下一个人将不得不不断问自己“谁编写了这个函数，它将被称为什么 - FooBar() 或 fooBar( )?”
当您导入 3rd 方库时，这种事情会变得更加棘手 - 您不想重写它们，但它们的代码风格可能与您的不匹配。所以最后，你会得到几种不同的命名约定，最好在“我们的代码”和“他们的代码”之间划清界限。
【讨论】：
通常，为了符合样式指南而对代码库进行大规模更改只是引入新错误的一种方式，几乎没有附加价值。
这意味着您应该：
更新您正在处理的代码，使其在处理时符合指南。
使用代码中的约定来辅助未来的维护工作。
我推荐 2.，但匈牙利符号让我的眼睛流血：p。
【讨论】：
如果您正在维护其他人编写的代码，并且其他人将在您之后维护，那么您应该对所有相关人员负责，不要进行无缘无故的更改。当他们进入源代码控制系统查看您更改的内容时，他们应该看到解决您正在处理的问题所必需的内容，而不是一百万个差异，因为您进行了一堆全局搜索并将代码替换或重新格式化为符合您最喜欢的大括号匹配约定。
当然，如果原始代码真的很烂，那么所有的赌注都没有了。
【讨论】：
一般来说，是的，在这种情况下，我会优先考虑约定和可读性而不是标准。没有人喜欢这个答案，但保持代码可长期维护是正确的做法。
当一个优秀的程序员阅读代码时，他应该能够解析变量名并在他的脑海中跟踪几个——只要它们一致，至少在源文件内是这样。但是如果你打破了这种一致性，它可能会迫使阅读代码的程序员遭受一些认知失调，这会使跟踪变得更加困难。这不是杀手——优秀的程序员会度过难关，但他们会诅咒你的名字，并可能将你发布到TheDailyWTF。
【讨论】：
我当然会继续使用相同的命名约定，因为它会使代码保持一致（即使它一直很丑陋）并且比混合变量命名约定更具可读性。人类的大脑似乎很擅长模式识别，你真的不想通过无缘无故地打破所说的模式来给大脑扔一个曲线球。
也就是说，我不过是几个匈牙利符号，但如果这是你必须使用的......
【讨论】：
如果文件或项目已经使用一致的样式编写，那么您应该尝试遵循该样式，即使它与您现有的样式冲突/矛盾。代码风格的主要目标之一是一致性，因此，如果您将不同的风格引入已经（内部）一致的代码中，您就会失去一致性。
如果代码写得不好并且需要一定程度的清理才能理解它，那么清理样式就成了一个更相关的选择，但只有在绝对必要时才应该这样做（尤其是在没有单元测试的情况下），因为您可能会引入意外的重大更改。
【讨论】：
当然，是的。我认为最好不要遵循原始程序员的命名约定的一种情况是原始程序员（或从那时起修改代码的后续开发人员）未能遵循任何一致的命名约定。
【讨论】：
是的。我实际上在标准文档中写了这个。我在我现在的公司创建：
现有代码取代所有其他标准和实践（无论是行业标准还是本文档中的标准）。在大多数情况下，您应该修改您的代码以匹配相同文件中的现有代码，原因有两个：
- 避免在单个模块/文件中包含多个不同的样式/模式（这与标准的目的相矛盾并妨碍可维护性）。
- 重构现有代码的工作往往会不必要地增加成本（耗时且有利于引入新错误）。
【讨论】：
-
我也这样做了 - 规则 1“您必须保持现有代码库保持相同的样式、约定和其他格式。这优先于所有其他规则”。规则 2+...通常的东西。它非常适合拥有编码标准，然后让常识占上风。
就我个人而言，每当我接手一个具有不同变量命名方案的项目时，我倾向于保留以前程序员使用的相同方案。我唯一不同的是对于我添加的任何新变量，我在变量名前加了一个下划线。通过这种方式，我可以快速查看我的变量和代码，而无需进入源历史记录和比较版本。但是当涉及到我继承简单不可读的代码或 cmets 时，我通常会仔细检查它们并尽我所能清理它们而不重写整个事情（它已经到了那个）。组织是拥有可扩展代码的关键！
【讨论】：
如果我可以阅读代码，我（尝试）采用相同的约定 如果它无论如何都不可读，我需要重构并因此改变它（取决于它的样子）相当大
【讨论】：
-
很好的测试，说实话有些代码很仓促，而原作者只是做了一些管道，在这些情况下，重构是至关重要的
视情况而定。如果我正在构建一个新应用程序并从具有垃圾变量命名的旧应用程序中窃取代码，我将在将其放入我的应用程序后进行重构。
【讨论】：
是的.. 有一点比走进一个有两种截然不同的风格的应用程序更令人沮丧。我最近从事的一个项目有两种不同的文件操作方式，两种不同的屏幕实现方式，两种不同的基本结构。第二位编码员甚至将新功能作为从主代码调用的 dll 的一部分。维护是一场噩梦，当我在一个部门工作时，我必须同时学习范式和希望。
【讨论】：
在罗马时像罗马人那样做。
（除了索引变量名称，例如“iArrayIndex++”。别再纵容这种白痴了。）
【讨论】：
-
如果罗马人有像“rrrrrrrrrrrrrrr++”这样的索引变量怎么办？
-
您知道罗马人没有零，因此无法终止他们的字符串吗？ :-)
-
索引变量名不受“罗马”政策的约束。因此，您可以将其更改为“r++”。除非它是一个全局变量；在那种情况下，无论如何你都注定要失败。
-
Tomblin，这就是你有 Pascal 字符串的原因。
-
paul，Joel 有一篇很棒的博客，介绍了以 null 结尾的字符串。另外，如果罗马人没有零，他们是如何使用数组的？？？我不明白..数组并非总是从零开始:) 那说我有一个同事根据访问对象的方法切换基于零和基于 1。哎呀！
我认为修复错误是一种外科手术。进去，尽可能少打扰，修理它，出去，尽可能少留下你在那里的痕迹。
【讨论】：
我愿意，但不幸的是，在我之前的几个开发人员没有遵守这个规则，所以我有几个命名约定可供选择。
但有时我们有时间把事情搞清楚，所以最后会很干净。
【讨论】：
如果代码已经有一致的风格，包括命名，我会尝试遵循它。如果以前的程序员不一致，那么我可以随意应用公司标准，如果没有任何公司标准，则可以使用我的个人标准。
在任何一种情况下，我都会尝试通过使用 cmets 来标记我所做的更改。我知道现在的 CVS 系统通常不会这样做，但我仍然喜欢这样做。
【讨论】：
不幸的是，大多数时候答案是肯定的。大多数时候，代码没有遵循良好的约定，因此很难遵循先例。但为了可读性，有时需要顺其自然。
然而，如果它是一个足够小的应用程序，我可以重构大量现有代码以更好地“闻”起来，那么我会这样做。或者，如果这是更大的重写的一部分，我也将开始使用当前的编码标准进行编码。但通常情况并非如此。
【讨论】：
如果现有应用程序中有标准，我认为最好遵循它。如果没有标准（制表符和空格混合，大括号无处不在......哦，恐怖），那么我会做我认为最好的事情，并且通常通过格式化工具（如 Vim）运行现有代码。如果有连贯的样式，我将始终保留现有代码的大写样式等。
我对这条规则的一个例外是，除非有人用枪指着我的头，否则我不会使用匈牙利符号。我不会花时间重命名现有的东西，但我添加的任何新东西都不会带有任何匈牙利疣。
【讨论】：