假设您继承了一个 C# 代码库，该代码库使用一个具有 200 个静态方法的类来提供核心功能（例如数据库查找）。在那个班级的许多噩梦中，匈牙利符号（不好的那种）的大量使用。
您会重构变量名称以删除匈牙利符号，还是不理会它们？
如果您选择更改所有变量以删除匈牙利符号，您的方法是什么？
Robert S.
问问题
3108 次
20 回答
17
别管它。你的时间有更好的用途。
于 2008-10-13T20:01:54.670 回答
17
重构——我发现这种规模的匈牙利符号确实会干扰代码的自然可读性，而练习是熟悉那里的内容的好方法。
但是，如果有其他团队成员知道代码库，则您需要就重构达成共识，并且如果任何变量暴露在一个项目之外，那么您将不得不让他们独自一人。
于 2008-10-13T20:04:46.023 回答
14
右键单击变量名称，Refactor -> Rename。
有 VS 插件也可以做到这一点，但内置方法对我来说很好用。
于 2008-10-13T20:01:05.670 回答
4
我会怎么做？假设我只需要维护代码而不以任何重要的方式重写它？别管它。当我添加代码时，使用现有的风格，意思是，使用那种丑陋的匈牙利符号（就像这让我觉得很脏。）
但是，嘿，如果你真的渴望重构，那么一次只做一点。每次处理它时，都要花十分钟重命名变量。稍微整理一下。几个月后你可能会发现它像口哨一样干净......
于 2008-10-13T20:07:45.580 回答
4
不要忘记有两种匈牙利符号。
最初的 Charles Simonyi HN，后来被称为 App's Hungarian 和后来被称为 System Hungarian 的令人憎恶的东西，在一些啄木鸟（这是一个技术术语）之后完全误解了Simonyi 的原始论文。
不幸的是，系统 HN 被 Petzold 和其他人传播，成为今天被正确认可的更占主导地位的堕胎。
阅读 Joel 关于原始 Apps Hungarian Notation 意图的精彩文章，并为匆忙中丢失的内容感到抱歉。
如果您拥有的是 App's Hungarian，那么在阅读了 Charles Simonyi 的原始文章和 Joel 的文章之后，您可能会想要保留它。
如果你掉进了一堆热气腾腾的匈牙利语系统？
所有赌注都取消了！
哇！（捂着鼻子说）（-：
于 2008-10-13T21:19:01.693 回答
2
如果您感到幸运并且只是希望匈牙利语消失，请隔离使用的匈牙利语前缀并尝试在文件中搜索和替换以将它们替换为nothing，然后进行清理并重建。如果错误数量很少，只需修复它。如果错误数量很大，请返回并首先将其分解为逻辑（按域）类，然后单独重命名（IDE 会有所帮助）
于 2008-10-13T20:04:36.850 回答
2
我曾经在 VB6 时代虔诚地使用它，但是当 VB.NET 出现时就停止了，因为这是新的 VB 指南所说的。其他开发商没有。所以，我们有很多旧代码。当我对代码进行维护时，我会从我接触的函数/方法/子中删除符号。除非您对所有内容都进行了非常好的单元测试并且可以运行它们以证明没有任何 问题，否则我不会一次将其全部删除。
于 2008-10-13T20:07:40.417 回答
2
你这样做会破坏多少？这是一个重要的问题要问自己。如果有很多其他代码使用该库，那么您可能只是通过重命名练习为人们（也许是您）创建工作。
我会把它放在重构时要做的事情清单上。至少那时每个人都希望你（暂时）打破图书馆。
也就是说，我对命名不佳的方法和变量感到非常沮丧，所以我可以联系起来。
于 2008-10-13T20:09:51.300 回答
1
我不会用它来做一个项目。我会使用 VS 中的重构工具（实际上，我会使用 Resharper 的，但 VS 的工作正常）并以我被要求修改的任何方法修复所有变量。或者，如果我必须进行更大规模的更改，我会在我被要求理解的任何方法中重构变量名称。
于 2008-10-13T20:04:21.420 回答
1
如果您有合法的需要删除和更改它，我会使用内置的重构工具或 Resharper 之类的工具。
然而，我会同意 Chris Conway 的观点并问你为什么，是的，这很烦人，但同时，很多时候“如果它没有坏就不要修复它”的方法是真的是最好的方法！
于 2008-10-13T20:06:01.013 回答
1
只有当你直接使用它时才改变它。并确保您有一个准备好应用的测试平台，以确保它仍然有效。
于 2008-10-13T20:11:18.757 回答
1
我同意逐步淘汰匈牙利符号的最佳方法是在修改代码时重构代码。进行这种重构的最大好处是你应该围绕你正在修改的代码编写单元测试，这样你就有了一个安全网，而不是交叉手指并希望你不会破坏现有的功能。一旦你完成了这些单元测试，你就可以根据自己的喜好随意更改代码。
于 2008-10-13T20:46:22.727 回答
1
我想说一个更大的问题是你有一个包含 200（！）方法的类！
如果这是一个非常依赖/变化很大的类，那么可能值得重构以使其更可用。
在这方面，Resharper 是绝对必须的（你可以使用内置的重构工具，但 Resharper 更好）。
开始寻找一组相关的方法，然后将它们重构为一个漂亮的小内聚类。更新以符合您的最新代码标准。
编译并运行您的测试套件。
有更多的能量吗？提取另一个类。
磨损 - 没有麻烦；明天回来再做一些。在短短几天内，您将征服野兽。
于 2008-10-13T20:53:41.743 回答
1
我同意@Booji 的观点——当您出于其他一些好的原因已经访问代码时，按例行程序手动执行。然后，您将摆脱最常见的问题，剩下的由谁来关心。
我想问一个类似的问题，只是在我的情况下，有问题的代码是我自己的。我有一个非常古老的习惯，即使用 FoxPro 时代的“坏种”匈牙利语（打字很弱，范围界定不寻常）——我最近才改掉这个习惯。
这很难——这意味着在你的代码库中接受不一致的风格。就在一周前，我终于说出了“screw it”并开始了一个不带字母“p”的参数名称。我最初感受到的认知失调已经让位于自由感。世界并没有走到尽头。
于 2008-10-13T21:00:14.367 回答
1
我一直在解决这个问题的方法是在遇到变量时一次更改一个变量，然后在您回来进行更深入的更改时执行更全面的更改。如果你像我一样，变量的不同命名法会让你疯狂一段时间，但你会慢慢习惯的。关键是一次一点地削减它，直到你拥有一切所需的地方。
或者，你可以完全抛弃你的变量，只让每个函数返回 42。
于 2008-10-13T21:49:49.460 回答
0
在我看来，更大的问题是 200 方法的God Object类。我建议仅删除匈牙利符号的重构本身就是一种低价值、高风险的活动。除非围绕该类有大量的自动化单元测试可以让您对重构有信心，否则我认为您应该完全不理会它。
我想这样的一组测试不太可能存在，因为遵循 TDD 实践的开发人员会（希望）自然地避免首先构建一个上帝对象 - 编写全面的测试将非常困难。
然而，消除上帝对象并建立一个单元测试库具有更高的价值。我的建议是寻找机会重构类本身——也许当出现合适的业务需求/更改时需要更改该代码（因此希望附带一些购买和付费的系统和回归测试）。您可能无法证明一次性重构整个事物的努力是合理的，但您可以在机会出现时逐步进行，并测试更改。通过这种方式，您可以一点一点地将意大利面条代码转换为具有全面单元测试的更干净的代码库。
如果您愿意，您可以随时消除匈牙利语。
于 2008-10-13T21:26:25.717 回答
0
实际上，我在这里为应用程序扩展做同样的事情。我的方法是使用 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~
于 2009-11-25T15:55:09.763 回答
0
如果您只是为了重构而破坏代码，我会认真考虑让 i 独自一人，特别是，如果您要影响团队中可能依赖该代码的其他人。
如果您的团队对此重构感到满意，并投入时间来执行此操作（如果这意味着代码更具可读性/可维护性，将来可能会节省时间），请使用 Visual Studio（或您正在使用的任何 IDE ) 来帮助您重构代码。
但是，如果您的团队/老板不愿意承担这样的重大变化，我建议您采取一种有些非正统的、折中的方法。与其在一次扫描中完成所有重构，不如重构在正常维护期间需要触及的代码部分（更具体地说，函数）？随着时间的推移，这种缓慢的重构将使代码达到更清晰的状态，此时您可以通过最终扫描完成重构过程。
于 2011-06-01T20:15:05.583 回答
0
使用此java 工具删除 HN：
或者只是使用“replace”/“replace all”和下面的正则表达式将“c_strX”替换为“x”：
于 2019-12-16T01:48:54.087 回答
-1
我喜欢匈牙利符号。不明白你为什么要摆脱它。
于 2008-10-13T20:39:04.533 回答