解决方法名称中的拼写错误


73

我在代码库中通常使用的一种方法是拼写错误(并且早于我)。

这不仅激怒了我,不仅因为它的拼写错误,而且更重要的是,这使我在第一次键入它时总是总是弄错名字(然后我必须记住“哦,对,应该把它拼写错了……”)

我正在对原始方法进行一些更改。我是否应该借此机会重命名怪胎法?


12
您可以重命名吗?如果您无法控制的代码使用了它,则需要证明向后兼容中断。

16
*拼写错误。而且,您必须在调用该方法的任何地方进行更改。
JohnP 2014年

2
*拼写失误...或其他拼写?
HorusKol 2014年

2
@JohnP有三个,现在一个是固定的,而两个仍然不正确。巧合的是,很适合OP的名字。:)
幻灭了

3
我们必须不允许任何拼写错误!
Magus 2014年

Answers:


136

我是否应该借此机会重命名怪胎法?

绝对。

就是说,如果您的代码已作为API发布,则通常还应该保留拼写错误的方法,并将其转发给正确命名的方法(如果您的语言支持此类,则将其标记为过时)。


33
“转发到正确命名的方法”的想法很简单而且很聪明。关于“破窗”理论的有趣链接也是如此。
dev_feed 2014年

2
请注意,如果这是公共API的一部分,则可能不是向后兼容的更改(取决于语言)。这并不是听起来那么不可能。如果我必须从现有的API继承一个拼写错误的名称,那么我肯定会解决这个问题。
Voo

10
@voo-是吗?哪种语言会使添加新方法(并更改一种方法的实现以实现相同的确切行为)与向后兼容?
Telastyn 2014年

3
@Telastyn有时添加一些说Web服务的方法可能很棘手。例如,某些客户端不愿更改WSDL,突然拒绝与服务器对话。这是客户端中的一个实现问题,但是如果客户端是一个重要的客户端,您不想让它感到不安,那很可能会阻止您更改界面。
jwenting 2014年

17
@Telastyn如果接口上有misspelt方法名称(如Delphi / Java / C#中使用的接口类型),则添加名称的正确拼写版本可能会破坏该接口的所有现有实现。
幻灭了

52

在某些情况下,您应避免进行此类重构:

  1. 如果该方法在公共接口中使用。一个典型的例子是拼写错误引用HTTP引用,错误拼写被保留,因为现在更改的拼写将有太多的反响。

  2. 如果代码基础未包含在任何测试中。 任何重构都应在经过测试的代码上进行,以便能够进行回归测试。重构未经测试的代码库尤其危险。如果您确实有很多时间,请从开始添加测试开始;如果您在时间紧迫的情况下工作,那么如果您想准时交货,最好不要冒险引入细微的错误。

  3. 如果该方法可以以一种不寻常的方式使用,则实际上使它的使用(通过Ctrl + F或自动重构工具)找不到。例如,在C#中,可以通过反射调用方法,从而使Visual Studio的“重命名”对话框无效。在JavaScript中,eval()很难找到内部调用的函数。在PHP中,变量变量可能会引起问题。

  4. 如果项目规模巨大,并且其他团队可以使用该方法。这类似于第一点,即您提供给其他团队的界面可以被视为公共界面。

  5. 如果您处理的是至关重要的项目。可能的是,拼写错误并不太重要,不足以证明几个月的文书工作以更改方法的名称,并确保不会导致任何患者接受十倍于授权放射线或任何梭子来误算其速度。

在任何其他情况下,请随时重命名该方法。


1
对于提及反射的评论+1,这不止一次咬我。
DaveShaw 2014年

33
如果您的至关重要的项目足够脆弱,以至于一丁点的重构都可能杀死某人,那么它足够脆弱,以至于没有人会相信他们的生活。如果您甚至无法重命名方法,您将如何确定您的新功能或简化的用户界面不会引入威胁生命的错误?
user2357112 2014年

2
同样,如果一个更改的方法名称导致额外的几个月书面工作(而不是说,大多数情况下文书工作会同时处理所有其他同时更改的事情),那么编程到文书工作之间的平衡就会出现偏差。数个数量级,并且不更改系统就不可能完成任何重大改进。
user2357112 2014年

8
@ user2357112:我从来没有说过一点点的重构就有可能杀死某人。这不是要杀死某个人,而是要使一切成为可能,以减轻剩余的0.001%的Bug风险。这需要正式的授权。这需要几层测试。这需要形式主义。这禁止“我想快速重命名此方法,希望它能起作用!” 行为。对生命至关重要的项目使用的技术对于任何业务应用程序来说都是完全浪费时间和金钱的。这就是为什么它们如此可靠(且昂贵)的原因。
Arseni Mourzenko 2014年

5
@ user2357112:正如MainMa指出的那样,这与休闲商务应用无关。它涉及经过广泛测试/验证的特殊软件。如果在某处通过反射调用该方法怎么办?如果某些预/后编译工具对此有所帮助怎么办?那文档呢?那其他使用它的团队呢?他们使用反射吗?如果......现实生活有时会非常复杂。有时候,最好不要更改方法名称,而不要以防弹方式验证是否有任何后果。
dagnelies

30

我几个月前就已经做到了(出于不同的原因)。我采取的步骤(语言是Perl):

  1. 重命名方法。将旧名称别名为新名称(这不应中断任何代码,因为该方法可以通过任何一个名称调用)。
  2. 告知其他开发人员名称更改及其原因,告诉他们从现在开始使用新名称。
  3. Grep旧名称的代码库,解决所有出现的问题。
  4. 记录对旧名称的任何使用(此时使用旧名称仍然可以使用)。解决这些情况。
  5. 等待(执行4时),直到日志中没有其他条目出现。
  6. 打破别名。创建一个使用旧名称的方法,该方法会引发致命异常并显示有关名称更改的消息。
  7. 一段时间后,删除具有旧名称的方法。

    当然,您的里程会有所不同。


一项改进-不要依靠grep查找旧名称的用户,也不必登录转发器。
Ben Voigt 2014年

@BenVoigt#4不是吗?
鲍勃

6

一种不破坏任何现有代码的好方法是将新方法名称链接到旧方法中,例如

private void MyNewMethodName()
{
    TheOldMethodName();
}

然后将旧方法标记为过时(如果您的语言支持)。这样,任何现有代码仍然可以使用,您可以逐渐从代码库中消除所有旧的拼写错误。最终,您甚至可以将方法主体复制/粘贴到新方法中,然后删除旧方法。

正如ivo在评论中所说:/ Edit要做的更好的事情是将代码从中TheOldMethodName移入MyNewMethodName并从旧方法中调用新方法。这也将有助于开发人员了解代码所属的地方。


2
我同意你的方法。我也会这样做。这是最理智,清晰和安全的重构方法。最好的方法是将代码从旧方法移到新方法,并使旧代码使用新方法。如果代码库在时间轴上进行了几次迭代,则只需要删除旧的不建议使用的方法即可。
Ivo Limmen 2014年

1
@IvoLimmen这是一个很好的建议。这样,人们就可以使用新方法来获得更大的收益,这将消除新方法中过时调用旧方法的警告。我将其添加到我的答案中。
雷米

1

重命名方法:

  • 通过重构来做到这一点,以免您要做的工作超出您的期望
  • 如果您的IDE支持自动补全,请在引用该方法时使用它

这是您可以选择的两个选择。我希望使用自动完成功能(例如Eclipse IDE),而无需键入方法名称。要重命名;只要确保您找出调用该方法的内容并在每个位置更改直接引用即可。重构将是您的朋友,但这样做时要格外小心。


0

我通常建议是,将其重命名。

此处的其他答案列出了为什么您不希望重命名的充分理由,因此,如果您遇到这种情况,则可以使用正确的名称和实现创建一个新方法,并更改旧方法以调用新方法。如果您的语言支持,则将旧的标记为已弃用。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.