2022年了，匈牙利命名法的遗毒还在危害人间，是时候彻底摒弃匈牙利命名法了，理由如下：

　　1.变量的类型由其含义决定。这是最重要的反对理由。比如money的类型就是money_t，比如object_size的类型就是size_t，事实上size_t是unsigned long的类型别名。类型编码进变量名，既多余，也无必要，且不能涵盖所有情况，画蛇添足。

　　2.缺乏一致可解释性。好的规则应该是一致性可解释的，它应该能够在它的问题集内一致性的应用规则，遵从规则只需无脑执行，Do not let me think，匈牙利不满足，它甚至不能胜任变量命名。

　　(a) 比如int的前缀到底是i还是n，char的前缀是c还是ch？那const呢？char* 是str？那const char* x[]呢？pcstra？太啰嗦了。

　　(b) C++的模板表示参数化类型，类型是不确定的，怎么加前缀？匈牙利在C语言是难以实施的，在C++是无法实施的。

　　(c) MS不仅为基本数据类型定义前缀，还为自定义类型定义前缀，比如h表示句柄，wnd表示窗口，re表示正则，fn表示函数，函数指针pfn？那如果再出现一堆概念，26个字母大概不够用吧。这么复杂的规则确定能记住？确定对项目有帮助？

　　2.修改类型困难。如果把变量类型编码进变量名，哪天short不够，改成int，岂不是要把所有s_var全改成i_var？而变量改类型也很常见吧。

　　3.冗余，有违精简原则。好的代码应该是清晰简短的，匈牙利命名法声称利于阅读代码，实际效果恰恰相反。

　　(a) 每次见到一个变量，比如puiindex，它远不如index明晰，我需要在脑海中先过滤掉pui这个无用的前缀，而实际上这个预处理过程完全多余。

　　(b) 第一次见到CFont这种类就觉得很奇怪，C是什么？Class首字母吗？为什么一个类型还要加个前缀？把本来通顺的词搞得那么别扭？

　　(c) 软件强调避免信息冗余，type name已经是一个完整的信息表达式，能准确无误的表达它的含义，在匈牙利命名中，就变成了type type_name; 很显然，type的信息冗余了。

　　4.业界主流观点反匈牙利。为什么这么说呢？Top开源项目和Top公司没有一个还在使用匈牙利命名法（找出一个算我输），包括STD C库，C++标准库STL没用，说句不好听的，主张匈牙利命名法可能是开源代码看的少。

　　5.匈牙利命名法是历史的产物，注定进历史的垃圾堆。就像GIT替代SVN一样，技术总在进步，匈牙利出现的时候，我猜想可能是为了弥补IDE的不足，但现在IDE已经进化到鼠标一放上去就能提示变量定义了。

　　6.MS已经公开宣称放弃匈牙利命名法，而且号召大家不再使用。这个已经足够说服力了，如果它真的那么有效，为什么MS抛弃它？（之前MS推崇经常被挺匈牙利派作为依据，尴尬）

　　为什么还有那么多人在坚持匈牙利呢？

　　我给出的答案是“惯性的力量”，而这种惯性是不知不觉的，但惯性阻碍进步，而优秀程序员最本质的要求就是好奇和开放，因循守旧，一昧按老规矩办，甚至失去思辨能力，值得警惕。

　　反匈牙利命名法又分温和派和激进派，无论是温和派还是激进派，核心观点都是反匈牙利。

　　有个大V在帖子中说：“感觉作者还是顾忌了大家的情绪，说了一些匈牙利的好话…”然后直言不讳的说挺匈牙利的是代码写的太少了，导致大家过于关注它的态度，而忽视了它的观点，但其实，观点才是重要的，我认为倒不一定是代码写的少，开源代码看的少几乎是一定的，文章中其他的说的都对。