如果你从某人那里接手一个项目来做简单的更新，你会遵循他们的命名约定吗？我刚收到一个项目，以前的程序员到处使用匈牙利符号。我们的核心产品有一个命名标准，但多年来我们有很多人做自定义报告，做他们想做的任何事情。
不过，我没有时间更改代码中已经存在的所有变量名称。
我倾向于继续他们的命名约定以保持可读性。
wonderchook
问问题
1082 次
20 回答
26
是的，我愿意。它使继承它的人更容易跟随你。如果真的很难理解，我会尝试稍微清理一下代码以使其更具可读性。
于 2008-11-12T14:37:43.460 回答
5
如果您没有将所有现有代码更改为您的标准，那么只要您更改这些文件，我会说坚持原始约定。在同一个文件中混合两种风格的代码正在破坏一致的代码风格所带来的任何好处，下一个人将不得不不断问自己“谁编写了这个函数，它将被称为什么 - FooBar() 或 fooBar( ）？”
当您导入 3rd 方库时，这种事情会变得更加棘手——您不想重写它们，但它们的代码风格可能与您的不匹配。所以最后，你会得到几种不同的命名约定，最好在“我们的代码”和“他们的代码”之间划清界限。
于 2008-11-12T14:41:47.633 回答
5
我同意建议保留作者编写的代码，只要该代码内部一致即可。如果代码由于不一致而难以遵循，您有责任对未来的维护者（可能是您）负责，使其更清晰。
如果您花费 40 个小时来弄清楚一个函数的作用，因为它使用了命名不佳的变量等，您应该重构/重命名以清楚起见/添加评论/做任何适合这种情况的事情。
也就是说，如果唯一的问题是作者使用的最一致的风格与公司标准或您习惯的风格不同，我认为您正在浪费时间重命名所有内容。此外，如果原始作者仍然可以回答问题，您可能会失去专业知识的来源，因为他将不再识别代码。
于 2008-11-12T14:54:14.957 回答
3
通常，为了符合风格指南而对代码库进行大规模更改只是引入新错误的一种方式，几乎没有附加价值。
这意味着您应该：
更新您正在处理的代码，使其在处理时符合指南。
使用代码中的约定来帮助未来的维护工作。
我推荐 2.，但匈牙利符号让我的眼睛流血：p。
于 2008-11-12T14:39:14.377 回答
3
如果您正在维护其他人编写的代码并且其他人将在您之后维护，那么您应该对所有相关人员负责，不要进行无缘无故的更改。当他们进入源代码控制系统查看您更改的内容时，他们应该看到解决您正在处理的问题所必需的内容，而不是一百万个差异，因为您进行了一堆全局搜索并将代码替换或重新格式化为适合您最喜欢的大括号匹配约定。
当然，如果原始代码真的很糟糕，那么所有的赌注都没有了。
于 2008-11-12T14:40:21.333 回答
2
一般来说，是的，在这种情况下，我会寻求约定和可读性而不是标准。没有人喜欢这个答案，但保持代码长期可维护是正确的做法。
当一个优秀的程序员阅读代码时，他应该能够解析变量名并在他的脑海中跟踪几个——只要它们一致，至少在源文件内。但是如果你打破这种一致性，它可能会迫使阅读代码的程序员遭受一些认知失调，这会使跟踪变得更加困难。这不是杀手——优秀的程序员会度过难关，但他们会诅咒你的名字，并可能将你发布到TheDailyWTF上。
于 2008-11-12T14:40:01.397 回答
2
我当然会继续使用相同的命名约定，因为它会使代码保持一致（即使它一直很丑陋）并且比混合变量命名约定更具可读性。人类的大脑似乎很擅长模式识别，你真的不想通过无缘无故地打破所说的模式来给大脑一个曲线球。
就是说，我不过是几个匈牙利符号，但如果那是你必须使用的......
于 2008-11-12T14:40:34.623 回答
2
如果文件或项目已经使用一致的样式编写，那么您应该尝试遵循该样式，即使它与您现有的样式冲突/矛盾。代码风格的主要目标之一是一致性，因此，如果您将不同的风格引入已经一致（在其自身内部）的代码中，您就会失去这种一致性。
如果代码写得不好并且需要一定程度的清理才能理解它，那么清理样式就成为一个更相关的选择，但只有在绝对必要时才应该这样做（尤其是在没有单元测试的情况下）运行引入意想不到的重大变化的可能性。
于 2008-11-12T14:42:00.190 回答
2
绝对没错。我认为最好不要遵循原始程序员的命名约定的一种情况是原始程序员（或从那时起修改代码的后续开发人员）未能遵循任何一致的命名约定。
于 2008-11-12T14:43:06.960 回答
2
是的。我实际上在标准文档中写了这个。我在我现在的公司创建：
现有代码取代所有其他标准和实践（无论它们是行业标准还是本文档中的标准）。在大多数情况下，您应该修改您的代码以匹配相同文件中的现有代码，原因有两个：
- 避免在单个模块/文件中包含多个不同的样式/模式（这与标准的目的相矛盾并妨碍可维护性）。
- 重构现有代码的努力往往会不必要地增加成本（耗时且有利于引入新错误）。
于 2008-11-12T15:43:08.727 回答
1
就我个人而言，每当我接手一个具有不同变量命名方案的项目时，我倾向于保留以前程序员使用的相同方案。我唯一不同的是对于我添加的任何新变量，我在变量名前加了一个下划线。通过这种方式，我可以快速查看我的变量和代码，而无需进入源历史记录和比较版本。但是当涉及到我继承简单不可读的代码或注释时，我通常会仔细检查它们并尽我所能清理它们，而无需重新编写整个东西（它已经到了）。组织是拥有可扩展代码的关键！
于 2008-11-12T14:40:42.237 回答
1
如果我可以阅读代码，我（尝试）采用相同的约定，如果它不可读，我需要重构并因此改变它（取决于它的样子）相当大
于 2008-11-12T14:40:44.217 回答
1
依靠。如果我正在构建一个新应用程序并从具有垃圾变量命名的旧应用程序中窃取代码，我将在将其放入我的应用程序后进行重构。
于 2008-11-12T14:41:31.533 回答
1
是的.. 有一点比走进一个有两种截然不同的风格的应用程序更令人沮丧。我最近从事的一个项目有两种不同的文件操作方式，两种不同的屏幕实现方式，两种不同的基本结构。第二位编码员甚至将新功能作为从主代码调用的 dll 的一部分。维护是一场噩梦，当我在一个部门工作时，我必须同时学习范式和希望。
于 2008-11-12T14:44:10.013 回答
1
在罗马做到入乡随俗。
（除了索引变量名称，例如“iArrayIndex++”。停止宽恕这种白痴。）
于 2008-11-12T14:45:29.327 回答
1
我认为修复错误是一种外科手术。进去，尽可能少打扰，修理它，出去，尽可能少留下你在那里的痕迹。
于 2008-11-12T14:48:48.787 回答
1
我这样做了，但不幸的是，在我之前的几个开发人员没有遵守这个规则，所以我有几个命名约定可供选择。
但有时我们有时间把事情整理好，所以最终，它会变得又好又干净。
于 2008-11-12T14:57:27.740 回答
1
如果代码已经有一致的风格，包括命名，我会尝试遵循它。如果以前的程序员不一致，那么我可以随意应用公司标准，如果没有任何公司标准，我可以使用我的个人标准。
在任何一种情况下，我都会尝试通过用评论框起来来标记我所做的更改。我知道在当今的 CVS 系统中这通常不会完成，但我仍然更喜欢这样做。
于 2008-11-12T15:06:14.323 回答
1
不幸的是，大多数时候答案是肯定的。大多数时候，代码没有遵循良好的约定，因此很难遵循先例。但是为了可读性，有时需要顺其自然。
但是，如果它是一个足够小的应用程序，我可以重构大量现有代码以更好地“闻”起来，那么我会这样做。或者，如果这是更大重写的一部分，我也将开始使用当前的编码标准进行编码。但通常情况并非如此。
于 2008-11-12T15:14:23.493 回答
0
如果现有应用程序中有标准，我认为最好遵循它。如果没有标准（制表符和空格混合，大括号无处不在......哦，恐怖），那么我会做我认为最好的事情，并且通常通过格式化工具（如 Vim）运行现有代码。如果有连贯的风格，我将始终保留现有代码的大写风格等。
我对这条规则的一个例外是，除非有人用枪指着我的头，否则我不会使用匈牙利符号。我不会花时间重命名现有的东西，但我添加的任何新东西都不会有任何匈牙利疣。
于 2008-11-12T15:43:27.743 回答