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在帖子中說：“感覺作者還是顧忌了大家的情緒，說了一些匈牙利的好話…”然后直言不諱的說挺匈牙利的是代碼寫的太少了，導致大家過於關注它的態度，而忽視了它的觀點，但其實，觀點才是重要的，我認為倒不一定是代碼寫的少，開源代碼看的少幾乎是一定的，文章中其他的說的都對。