摆脱匈牙利命名法的最佳方法是什么？

Question

摆脱匈牙利命名法的最佳方法是什么？

coding-stylerefactoringhungarian-notation

4

假设你继承了一个使用一个类和200个静态方法来提供核心功能（如数据库查找）的C#代码库。在那个类中，有许多噩梦，包括大量使用匈牙利标记（糟糕的那种）。

你会重构变量名以删除匈牙利标记，还是保持原样？

如果你选择改变所有变量以删除匈牙利标记，你的方法是什么？

- Robert S.

5

一个有200个静态方法的类？我认为你比匈牙利命名法还要更多问题。;-) - Rob Wells

编写一个工具/插件并在Github上分享。它不必完全正确，只需是一个辅助工具。或者直接使用替换功能。 - Leon

20个回答

17

就让它保持不变。你的时间有更好的用途。

- Chris Conway

你怎么知道他还能用时间做什么？你是否认识他或者了解他的项目？或者在这种情况下可读性受到了多大的影响？ - Alan Hensel

1

他的时间可能是毫无价值的。这是真的。
不，我不这样认为。
如果只是“匈牙利命名法”（如问题所述），而不是“匈牙利命名法与可怕、晦涩且常常误导的变量名称选择相结合”，那么它就不会那么糟糕了。

- Chris Conway

艾伦：成本效益分析时间。重构那个混乱的代码，然后重新测试所有内容，只是为了清理变量名称需要花费多少时间？如果代码是功能性的，那么就在变量名称上不要过于纠结，而是专注于更大的回报率重构。 - John Rudy

我赞同。什么样的大脑会使用匈牙利命名法编写C#代码？就让它保持原样吧。 - Marko Dumic

@Marko - 我希望我知道那个问题的答案。:( - Robert S.

@Marko Dumic - 我猜，匈牙利式的 :) - Rook

14

右键点击变量名，选择重构 -> 重命名。

也有一些Visual Studio插件可以完成此操作，但我觉得内置的方法已经足够好用了。

- AviewAnew

我建议您随着代码库的维护逐步进行重构。 - Jared

4

我该怎么做？假设我只需要维护代码而不重写它，那就不要轻易动它。当我确实需要添加代码时，遵循现有的风格，也就是使用那个丑陋的匈牙利命名法（尽管这让我感觉很糟糕）。

但是，如果你真的想要进行重构，那就一次只改一点点。每次工作时花十分钟重命名变量，稍微整理一下。几个月后，你可能会发现它变得干净如新。

- MDCore

我曾经也遇到过这种情况。我们维护的一些项目上有评论说：“我们不会这样写，但我们决定保持糟糕的风格以便于长期维护。”虽然有点不规范，但有时候这是正确的选择。 - John Rudy

4

不要忘记，匈牙利命名法有两种。

最初的Charles Simonyi HN，后来被称为App's Hungarian，以及后来的可怕的System Hungarian，是由一些混蛋（这是一个技术术语）完全误读了Simonyi的原始论文而产生的。

不幸的是，Petzold和其他人传播了System HN，使其成为今天应该被认为是更为主流的悲惨遭遇。

阅读Joel的出色文章，了解原始Apps Hungarian Notation的意图，并对在匆忙中失去的东西感到抱歉。

如果你拥有的是App's Hungarian，那么在阅读了Charles Simonyi的原始文章和Joel的文章之后，你可能会想要保留它。

如果你陷入了一堆System Hungarian？

所有的赌注都取消了！

哇！（捂着鼻子说）（-:）

- Rob Wells

请注意，我在问题中说的是“不好的那种”。 - Robert S.

我看到了这个，不确定你的意图是什么。也许可以编辑一下，提到Sys. HN，并添加链接到Joel的文章？顺便说一句，遗传Sys HN真是倒霉！(-: - Rob Wells

2

如果你觉得幸运，只是想让匈牙利语消失，那么请分离使用的匈牙利前缀，并尝试通过文件搜索和替换将它们替换为nothing，然后进行清理和重建。如果错误数量很少，只需修复即可。如果错误数量很大，请先按逻辑（按域）分类，然后逐个重命名（IDE将会帮助）。

- Steven A. Lowe

1

大胆的建议！最好为此编写一套非常好的单元测试。 - Alan Hensel

@[Alan Hensel]：这是一个健全性检查；-) 如果名称没有匈牙利前缀是唯一的，那么一切都会很好；如果不是，编译器将会抱怨...很多！需要采取另一种替代方案。 - Steven A. Lowe

2

我曾在VB6时代虔诚地使用它，但当VB.NET发布后，由于新的VB准则规定，我停止了使用。但其他开发者并没有停止使用，所以我们有很多旧代码中包含它。当我对代码进行维护时，会从我修改的函数/方法/子程序中删除此注释。除非你拥有真正好的单元测试来证明没有任何问题，并且可以运行这些测试来证明没有任何问题，否则不要一次性删除所有注释。

- Booji boy

2

你这样做会有多少破坏？这是一个重要的问题需要问自己。如果有很多其他代码使用该库，那么通过重命名操作可能只会为其他人（也许包括你）创建更多工作。

我建议在重构时将其列入待办事项清单。至少这样每个人都期望你会暂时破坏库。

话虽如此，我完全理解方法和变量命名不当所带来的挫败感。

- itsmatt

1

我不会把它变成一个项目。我会使用VS的重构工具（实际上，我会使用Resharper的，但VS的也很好用），并在我需要修改的任何方法中修复所有变量。或者如果我必须进行较大规模的更改，我会在任何我需要“理解”的方法中重构变量名。

- Robert Rossney

1

如果您有合法的需要删除和更改它，我建议使用内置的重构工具或类似Resharper的工具。

然而，我同意Chris Conway的观点，并向您提出一个问题：为什么要这样做呢？是的，这很烦人，但同时，“不破不立”的方法在很多时候确实是最好的选择！

- Mitchel Sellers

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Rob Walker · Accepted Answer

重构 -- 我认为在这个规模上使用匈牙利命名法会严重干扰代码的自然可读性，而且通过这个练习可以熟悉代码的内容。

但是，如果有其他团队成员熟悉此代码库，则需要就重构达成共识。如果任何变量在一个项目之外被暴露出去，则必须不予修改。