你是否遵循原始程序员的命名惯例？

Question

如果您接管某人的项目进行简单更新，您是否遵循他们的命名惯例？我刚收到一个项目，以前的程序员到处都使用匈牙利表示法。我们的核心产品有一个命名标准，但我们已经有很多人多年来做自定义报告并做他们想做的事情。

我没有时间更改代码中已有的所有变量名称。

为了继续他们的命名惯例，我倾向于可读性。

Answer 1

是的，我知道。这使得在您之后继承它的人更容易遵循。如果真的很难理解，我会尝试清理一下代码以使其更具可读性。

Answer 2

我同意建议将代码保留为作者写的，只要该代码内部一致，就可以了。如果由于不一致而难以遵循代码，则您有责任未来的维护者（可能是你）让它更清楚。

如果您花费40个小时来确定函数的功能，因为它使用了命名不佳的变量等，那么应该重构/重命名以获得清晰度/添加注释/做适合该情况的任何事情。

也就是说，如果唯一的问题是作者使用的大部分一致的风格与公司标准或你习惯的不同，我认为你浪费时间重命名一切。此外，如果原作者仍然可以提问，您可能会失去专业知识来源，因为他不再能够识别代码。

Answer 3

如果您没有将所有现有代码更改为您的标准，那么只要您更改这些文件，我就会坚持使用原始约定。在同一个文件中混合使用两种样式的代码会破坏一致的代码风格所带来的任何好处，而下一个人将不得不经常问自己“谁写了这个函数，它将被称为什么 - FooBar（）或fooBar （）＆QUOT;

当您导入第三方库时，这种事情变得更加棘手 - 您不想重写它们，但它们的代码风格可能与您的代码风格不匹配。所以最后，你最终会得到几种不同的命名约定，最好在“我们的代码”和“我们的代码”之间划清界限。和“他们的代码”。

Answer 4

通常，为了符合样式指南而对代码库进行批量更改只是一种引入新增缺点的方法。

这意味着您应该：

1. 在您处理时，更新您正在处理的代码以符合指南。

2. 使用代码中的约定来帮助未来的维护工作。

我推荐2.，但匈牙利表示法让我的眼睛流血：p。

Answer 5

如果你正在维护其他人写的代码，而其他人会在你之后维护代码，那么你应该向所有参与者做出无偿改变。当他们进入源代码控制系统看看你改变了什么时，他们应该看看解决你正在处理的问题需要什么，而不是一百万个差异，因为你做了一堆全局搜索并替换或重新格式化了代码适合你最喜欢的大括号匹配惯例。

当然，如果原始代码真的很糟糕，那么所有的赌注都会被取消。

Answer 6

一般来说，是的，在这种情况下，我会考虑常规和可读性而不是标准。没有人喜欢这个答案，但是保持代码长期可维护是正确的。

当一个优秀的程序员阅读代码时，他应该能够解析变量名并跟踪他脑中的几个 - 只要它们一致，至少在源文件中。但是，如果你打破这种一致性，它可能会迫使程序员阅读代码遭受一些认知失调，这将使得跟踪更加困难。这不是一个杀手 - 优秀的程序员会通过它，但他们会诅咒你的名字，并可能会发布你的 TheDailyWTF

Answer 7

我当然会继续使用相同的命名约定，因为它会保持代码的一致性（即使它一直很难看），并且比混合变量命名约定更具可读性。人类的大脑似乎相当擅长模式识别，你并不是真的想通过无偿破坏模式来让大脑变成曲线球。

那就是说，我只不过是一些匈牙利乐谱，但如果这就是你必须要合作的......

Answer 8

如果文件或项目已经使用一致的样式编写，那么您应该尝试遵循该样式，即使它与您现有的样式冲突/矛盾。代码风格的主要目标之一是一致性，因此如果您将代码中的不同样式引入已经一致的（在其自身内），则会失去一致性。

如果代码编写不好并需要进行一定程度的清理才能理解它，那么清理样式会成为一个更相关的选项，但只有在绝对必要时才会这样做（特别是如果没有单元测试）你可能会引入意想不到的突破性变化。

Answer 9

当然，是的。我不相信遵循原始程序员命名约定的一种情况是原始程序员（或从那时起修改过代码的后续开发人员）未能遵循任何一致的命名约定。

Answer 10

是。我实际上是在标准文档中写的。我在我现在的公司创建了：

现有代码取代所有其他标准和惯例（无论是行业标准还是本文档中的标准）。在大多数情况下，您应该对代码进行变色，以匹配相同文件中的现有代码，原因有两个：

1. 避免在单个模块/文件中出现多个不同的样式/模式（这与标准的目的相矛盾并妨碍可维护性）。
2. 重构现有代码的工作很容易造成不必要的代价（耗时且有利于引入新的错误）。

Answer 11

就个人而言，每当我接管一个具有不同变量命名方案的项目时，我倾向于保持前一个程序员使用的相同方案。我唯一不同的是我添加的任何新变量，我在变量名称之前放置了一个下划线。通过这种方式，我可以快速查看变量和代码，而无需进入源历史记录和比较版本。但是当谈到我继承简单不可读的代码或注释时，我通常会经历它们并尽可能地清理它们而不重写整个事情（它已经到了）。组织是拥有可扩展代码的关键！

Answer 12

如果我能读取代码，我（尝试）采用相同的约定 如果它无法读取，我需要重构并因此改变它（取决于它的相似之处）相当可观

Answer 13

取决于。如果我正在构建一个新的应用程序并使用垃圾变量命名从旧版应用程序中窃取代码，那么一旦我将其放入我的应用程序中，我就会重构。

Answer 14

是.. 有一个更令人沮丧的是，然后走进一个有两种截然不同的风格的应用程序。我经常研究的一个项目有两种不同的操作文件方式，两种不同的方式来实现屏幕，两种不同的基础结构。第二个编码器甚至使新功能成为从主代码调用的dll的一部分。主要是噩梦，我必须学习范式和希望，当我在一个部分时，我正在使用正确的一个。

Answer 15

在罗马时，像罗马人一样。

（索引变量名称除外，例如“iArrayIndex ++”。停止纵容这种白痴。）

Answer 16

我想把bug修复为外科手术。进去，尽可能少地打扰，修理它，离开，留下尽可能少的痕迹。

Answer 17

我这样做，但不幸的是，在我之前有几个开发人员没有遵守这个规则，所以我有几个命名约定可供选择。

但是有时候我们会把时间安排到最后，这样会很干净。

Answer 18

如果代码已经具有一致的样式，包括命名，我会尝试遵循它。如果以前的程序员不一致，那么如果没有任何公司标准，我可以自由地应用公司标准或我的个人标准。

在任何一种情况下，我都试着通过用注释构建它们来标记我所做的更改。我知道今天的CVS系统通常没有这样做，但我仍然喜欢这样做。

Answer 19

不幸的是，大多数时候答案是肯定的。大多数情况下，代码不遵循良好的约定，因此很难遵循先例。但为了便于阅读，有时需要顺其自然。

然而，如果它足够小的应用程序，我可以重构很多现有的代码来“闻”。更好，然后我会这样做。或者，如果这是更大的重写的一部分，我也将开始使用当前的编码标准进行编码。但通常情况并非如此。

Answer 20

如果现有应用中有标准，我认为最好遵循它。如果没有标准（标签和空格混合，大括号到处都是......哦，恐怖），那么我做我认为最好的，通常通过格式化工具（如Vim）运行现有代码。如果存在连贯的风格，我将始终保持现有代码的大写形式等。

我对这条规则的一个例外是我不会使用匈牙利表示法，除非有人拿枪对我说话。我不会花时间重新命名现有的东西，但是我添加的任何东西都不会有任何匈牙利疣。