摆脱匈牙利表示法的最佳方法是什么？

Question

假设您继承了一个C＃代码库，该代码库使用一个具有200个静态方法的类来提供核心功能（例如数据库查找）。在那个班级的许多噩梦中，大量使用匈牙利符号（坏的）。

您是否会重构变量名称以删除匈牙利表示法，还是将它们留下？

如果您选择更改所有变量以删除匈牙利表示法，那么您的方法是什么？

Answer 1

不要管它。你的时间有更好的用途。

Answer 2

重构 - 我发现这种规模的匈牙利符号确实会干扰代码的自然可读性，而练习是熟悉那些内容的好方法。

但是，如果有其他团队成员知道代码库，那么您需要就重构达成共识，如果任何变量暴露在一个项目之外，那么您将不得不将它们单独留下。

Answer 3

右键单击变量名称，Refactor - ＆gt;重命名。

有VS加载项也可以这样做，但内置方法对我来说很好。

Answer 4

我该怎么办？假设我只需要维护代码而不是重写它？ 单独留下它。当我做添加代码时，请使用现有的样式，意思是，使用那种丑陋的匈牙利符号（就像让我感觉脏一样。）< / p>

但是，嘿，如果你真的有一个 hankerin'fer refactorin'，那么就一次做一点。每次使用它都需要花费十分钟重命名变量。把事情整理一下。几个月之后，你会发现它像吹口哨一样干净......

Answer 5

不要忘记有两种匈牙利表示法。

原来的Charles Simonyi HN，后来被称为App的匈牙利人和后来被称为匈牙利系统的憎恶在一些啄木鸟（这是一个技术术语）后完全误读了Simonyi's original paper。

不幸的是，系统HN被Petzold和其他人传播，成为今天被正确认可的更主要的堕胎。

阅读Joel的excellent article关于原始Apps匈牙利表示法的意图，并为匆忙中丢失的内容感到抱歉。

如果您拥有的是App的匈牙利语，您可能希望在阅读原始的Charles Simonyi文章和Joel文章之后保留它。

如果你已经登上了匈牙利系统的热气腾腾的堆？

所有赌注都已关闭！

呼！ （一边抱着鼻子说）（ - ：

Answer 6

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

我会把它放在重构时要做的事情列表上。至少每个人都希望你（暂时）破坏图书馆。

也就是说，我对命名不佳的方法和变量感到沮丧，所以我可以联系起来。

Answer 7

我曾经在VB6时代虔诚地使用它，但是当VB.NET问世时就停止了，因为这是新的VB指南所说的。其他开发人员没有。所以，我们有很多旧的代码。当我对代码进行维护时，我会从函数/ methods / sub中删除符号。我不会立刻将它全部删除除非你已经完成了所有的非常好的单元测试并且可以运行它们以证明没有任何损坏。

Answer 8

如果你感到幸运并且只想让匈牙利人离开，请隔离使用的匈牙利语前缀并尝试搜索并替换文件以用 nothing 替换它们，然后进行清理并重建。如果错误的数量很小，只需修复它。如果错误的数量很大，请先返回并将其分解为逻辑（按域）类，然后单独重命名（IDE将有所帮助）

Answer 9

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

然而，我会同意克里斯康威的某种立场，并问你为什么，是的，这很烦人，但与此同时，很多时候“如果它没有完成，请不要修理它” “方法真的是最好的方法！

Answer 10

仅在您直接使用时更改它。并确保您已准备好应用测试平台，以确保它仍能正常工作。

Answer 11

我同意逐步淘汰匈牙利表示法的最佳方法是在修改代码时重构代码。进行这种重构的最大好处是你应该围绕你正在修改的代码编写单元测试，这样你就可以拥有一个安全网而不是交叉，希望你不要破坏现有的功能。完成这些单元测试后，您可以自由地将代码更改为您的内容。

Answer 12

我想说一个更大的问题是你有一个单独的200（！）方法的类！

如果这是一个非常依赖/更改的类，那么可能值得重构以使其更有用。

在这方面，Resharper是绝对必须的（你可以使用内置的重构东西，但Resharper更好）。

开始寻找一组相关的方法，然后将它们重构成一个很好的小型内聚类。更新以符合您的最新代码标准。

编译＆amp;运行你的测试套件。

有更多能量吗？提取另一个班级 破旧 - 没有麻烦;明天回来再做一些。在短短几天内，你就会征服野兽。

Answer 13

我同意@Booji - 当你因为其他一些正当理由访问代码时，按照例行程序手动完成。然后，你将获得最常见的，并关心其余的。

我想问一个类似的问题，只有在我的情况下，违规代码是我自己的。我有一个非常古老的习惯，就是在我的FoxPro时代使用匈牙利语中的“坏人”（打字很弱，不寻常的范围） - 这是我最近才开始的习惯。

这很难 - 这意味着在代码库中接受不一致的样式。就在一个星期前，我终于说“拧它”并开始一个没有字母“p”的参数名称。我最初认为的认知失调让位于一种自由的感觉。世界没有走到尽头。

Answer 14

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

Answer 15

我一直在解决这个问题的方法是在遇到这些问题时一次更改一个变量，然后在您回来做更深入的更改时执行更多的彻底更改。如果你和我一样，你的变量的不同命名会让你疯狂地疯狂一段时间，但你会慢慢习惯它。关键是要一次性消除它，直到你拥有它需要的所有东西。

或者，您可以完全抛弃变量，只需让每个函数返回42。

Answer 16

使用此java tool to remove HN：

或仅使用“ replace” /“ replace all”和以下正则表达式将“ c_strX”替换为“ x”：

Answer 17

如果你只是为了重构而打破代码，我会认真考虑让我独自一人，特别是，如果你要影响团队中可能依赖于该代码的其他人。

如果您的团队对这种重构没有问题，并且花时间去做这件事（这可能会节省时间，如果这意味着代码更易读/可维护），请使用Visual Studio（或任何IDE）您正在使用）帮助您重构代码。

然而，如果像这样的大变化不是你的团队/老板愿意承担的风险，我建议采用一种有点非正统的中途方法。为什么不重构在正常维护期间需要触摸的代码部分（更具体地说，函数），而不是在一次扫描中完成所有重构？随着时间的推移，这种缓慢的重构将使代码更加清晰，此时您可以通过最终扫描完成重构过程。

Answer 18

我实际上在这里为应用程序扩展做同样的事情。我的方法是使用VIM映射来搜索特定的匈牙利表示法前缀，然后删除它们并根据需要修复大小写。

示例（进入vimrc）：

"" Hungarian notation conversion helpers
"" get rid of str prefixes and fix caps e.g. strName -> name
map ,bs /\Wstr[A-Z]^Ml3x~
map ,bi /\Wint[A-Z]^Ml3x~
"" little more complex to clean up m_p type class variables
map ,bm /\Wm_p\?[A-Z]^M:.s/\(\W\)m_p\?/\1_/^M/\W_[A-Z]^Mll~
map ,bp /\Wp[A-Z]^Mlx~

Answer 19

对我来说，更大的问题就是200方法God Object类。我建议仅仅为了删除匈牙利符号进行重构本身就是一种低价值，高风险的活动。除非在整个课程中有大量的自动化单元测试，让你对重构有一定的信心，否则我认为你应该保持良好而且真正独自。

我想这样的测试集不太可能存在，因为跟随TDD实践的开发人员（希望）首先自然地避免构建一个神对象 - 编写全面的测试是非常困难的。

然而，消除上帝对象并获得单元测试基础具有更高的价值。我的建议是寻找重构类本身的机会 - 也许当合适的业务需求/变化出现时，需要对代码进行更改（因此希望能够购买和支付一些系统和回归测试）。你可能无法一次性重构整个事物的努力，但是你可以随着机会的出现逐一进行，并测试驱动变化。通过这种方式，您可以将意大利面条代码慢慢转换为更清晰的代码库，并进行全面的单元测试。

如果你愿意，你可以随意消灭匈牙利人。

Answer 20

我喜欢匈牙利的乐谱。不明白为什么你想要摆脱它。