如果你接手了一个项目来进行简单的更新，你会遵循他们的命名规范吗？我刚刚接到一个项目，之前的程序员在所有地方都使用了匈牙利命名法。我们的核心产品有一个命名标准，但是多年来我们已经有很多人进行了自定义报告并按照他们自己的意愿进行操作。
虽然我没有时间改变代码中已经存在的所有变量名称，但我倾向于为可读性继续使用他们的命名约定。
虽然我没有时间改变代码中已经存在的所有变量名称，但我倾向于为可读性继续使用他们的命名约定。
20个回答
26
是的，我这么做是为了让接手我的人更容易理解代码。如果难以理解，我会尽量清理代码，使其更易读。
- Kevin
3
这也是Kernighan和Pike在《编程实践》中的建议，出于相同的原因-持续的清晰度和可维护性。 - Harper Shelby
1这也是“常识”所推荐的；-)。 - Toon Krijthe
1有趣的是，在我们这个行业中，那种“常识”东西极度缺乏 :) - kemiller2002
5
如果你不打算将所有现有的代码改成符合你的标准，那么我建议只要在修改这些文件的时候坚持原始约定即可。在同一个文件中混合两种代码风格会破坏一致的代码风格所带来的任何好处，下一个人将不得不不断地问自己“谁编写了这个函数，它将被称为FooBar()还是fooBar()？”
当你导入第三方库时，这种情况变得更加棘手-你不想重写它们，但它们的代码风格可能与你的不匹配。因此，最终您将拥有几种不同的命名约定，最好在“我们的代码”和“他们的代码”之间划清界限。
当你导入第三方库时，这种情况变得更加棘手-你不想重写它们，但它们的代码风格可能与你的不匹配。因此，最终您将拥有几种不同的命名约定，最好在“我们的代码”和“他们的代码”之间划清界限。
- Enno
5
我认为只要代码在内部一致，保留作者编写的代码就可以了。如果代码由于不一致而难以跟踪，你有责任让它更清晰明了，这也是对未来维护者（可能是你自己）的负责。
如果你花费了40个小时来理解一个函数的作用，因为变量名命名不当等原因，那么你应该进行重构/重命名，并添加注释或者采取适当的方法来提高代码可读性。
话虽如此，如果唯一的问题是作者使用的大部分一致的风格与公司标准或者你习惯的不同，我认为你浪费时间改变所有东西。此外，如果原始作者仍然可以回答问题，你可能会失去专业知识来源，因为他将无法认出代码。
如果你花费了40个小时来理解一个函数的作用，因为变量名命名不当等原因，那么你应该进行重构/重命名，并添加注释或者采取适当的方法来提高代码可读性。
话虽如此，如果唯一的问题是作者使用的大部分一致的风格与公司标准或者你习惯的不同，我认为你浪费时间改变所有东西。此外，如果原始作者仍然可以回答问题，你可能会失去专业知识来源，因为他将无法认出代码。
- Sam Hoice
2
1+1，我从小就是童子军，他们教导我们要把去过的地方留得比来时更好。 - Robert Gould
对于Sam的聪明判断而非盲目遵循规则，我给予+1。对于Robert认识到黄金法则同样适用于软件，我给予+5。 :-) - Adam Liss
3
通常，为了符合样式指南而对代码库进行全面更改只是引入新错误的一种方式，实际帮助不大。这意味着你应该：
1. 在工作时更新你正在处理的代码，以符合指南。 2. 使用代码中的约定来帮助未来的维护工作。
我建议选择第二种方法，但匈牙利命名法让我感到头痛。 :p
1. 在工作时更新你正在处理的代码，以符合指南。 2. 使用代码中的约定来帮助未来的维护工作。
我建议选择第二种方法，但匈牙利命名法让我感到头痛。 :p
- zacherates
3
如果你在维护别人编写的代码，并且其他人将在你之后继续维护，那么你有责任不进行无谓的更改。当他们进入源代码控制系统查看你的更改时，他们应该只看到为解决问题而必要的更改，而不是因为进行了一堆全局搜索和替换或重新格式化代码以适应你喜欢的大括号匹配约定而产生的无数差异。当然，如果原始代码真的很烂，那就另当别论。
- Paul Tomblin
2
通常情况下，在这种情境下，我会选择传统和易读性而不是标准。没人喜欢听到这个答案，但这是为了长期保持代码的可维护性所必须做的正确事情。
当一个好的程序员在阅读代码时，他应该能够解析变量名并在脑海中跟踪多个变量 -- 至少在源文件内它们是一致的。但是，如果你打破了这种一致性，这可能会迫使阅读代码的程序员遭受一些认知失调，这会让跟踪变得更加困难。这不是问题的关键--好的程序员会解决它，但他们会诅咒你的名字，可能会将你发布在TheDailyWTF上。
当一个好的程序员在阅读代码时，他应该能够解析变量名并在脑海中跟踪多个变量 -- 至少在源文件内它们是一致的。但是，如果你打破了这种一致性，这可能会迫使阅读代码的程序员遭受一些认知失调，这会让跟踪变得更加困难。这不是问题的关键--好的程序员会解决它，但他们会诅咒你的名字，可能会将你发布在TheDailyWTF上。
- John Rudy
2
我肯定会继续使用相同的命名约定，因为它将使代码保持一致（即使它看起来很丑），并且比混合变量命名约定更易读。人类大脑似乎非常擅长模式识别，您真的不想通过毫无意义地打破该模式来使大脑受到影响。
话虽如此，我并不是匈牙利命名法的拥护者，但如果这是您要使用的命名约定...
- Timo Geusch
2
如果文件或项目已经使用一致的风格编写，则应尽量遵循该风格，即使它与您现有的风格冲突/矛盾。代码风格的主要目标之一是一致性，因此，如果您在已经一致（内部）的代码中引入不同的风格，则会失去这种一致性。
如果代码编写较差，需要进行某些清理才能理解，则清理风格成为更相关的选项，但只有在绝对必要时才应这样做（特别是如果没有单元测试），因为您可能会引入意外的破坏性更改。
- Scott Dorman
2
当然，是的。我认为唯一不建议遵循原始程序员命名约定的情况是当原始程序员（或此后修改代码的其他开发人员）未能遵循任何一致的命名约定时。
- Greg D
2
是的。我实际上在我的现任公司创建了一个标准文档，其中包括以下内容：
现有的代码优先于所有其他标准和惯例（无论它们是行业标准还是此文档中找到的标准）。在大多数情况下，您应该将您的代码变成与同一文件中的现有代码匹配，原因如下：
- 避免在单个模块/文件中具有多个不同的样式/模式（这与标准的目的相矛盾，并妨碍可维护性）。
- 重构现有代码的工作量容易不必要地更高（耗时长且容易引入新错误）。
- fallen888
1
我也这样做了 - 规则1：“您必须维护现有的代码库，保持相同的风格、约定和其他格式。这比所有其他规则都更重要。”规则2+...通常的东西。它非常适合制定编码标准，然后允许常识占主导地位。 - gbjbaanb
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接