匈牙利命名法

從事Windows下C/C++編程的人極可能遇到過相似nCount、stPerson這類風格的命名，這類風格的命名方式即爲匈牙利命名法。

匈牙利命名法起源

匈牙利命名法(HungarianNotation)是由匈牙利裔美國人Charles Simony發明的，因爲其單詞排列順序相似古怪的匈牙利姓名而得名。

實際上Charles Simony發明的是應用型匈牙利命名法，因爲被曲解、以訛傳訛，造成了咱們常見的系統型匈牙利命名法。文章開頭的兩個例子的風格來自於系統型匈牙利命名法。

這段歷史在Joel on Software的《讓錯的程式看得出錯》有詳細的介紹。

匈牙利命名法的構造

應用型匈牙利命名法和系統型匈牙利命名法都是經過前綴+對象描述的形式命名。

• 應用型匈牙利命名法
  前綴體現天然語義，主要是說明變量的應用屬性或業務屬性，抽象層次較高，如：

  若 Fahrenheit簡稱爲fah，Celsius 簡稱爲cel。下面的代碼咱們一眼就能看出問題：
  int fahTemp = celThermometer;
  由於華氏溫度和攝氏溫度確定不能直接賦值，它們之間有轉換關係，因此代碼邏輯錯誤。

• 系統型匈牙利命名法
  而匈牙利系統命名法的前綴是爲了說明變量的系統屬性，最經常使用的是變量類型，上面的例子改寫爲：
  int iTemp = iThermometer;

  i標識變量類型是int，咱們很難看出其中的問題。

系統型匈牙利命名法的缺點

Windows開發的聖經《Windows 程序設計》初版大量使用了匈牙利命名法，因此係統型匈牙利命名法是Windows開發的事實標準。但隨後的反對也愈演愈烈，在.net第一次發佈時達到了高潮。微軟在.net框架的《通用命名約定》中明確說明不建議使用匈牙利命名法。到如今，除了一些遺產代碼，新的代碼已經鮮見系統型匈牙利命名法了，並且《Windows 程序設計》第六版也不怎麼使用匈牙利命名法了。

我認爲其的幾個缺點：

• IDE流行，特殊標註類型已沒有必要
  有圖有真相：

圖中是Rust的代碼段，guess後面的String是IDE推斷出的，現代的工具已經很發達，能有效避免這種純手工的標註。
其餘語言同理。

• 抽象層次低，對問題排查沒有用處

類型不一致致使的問題，在大多數語言的編譯器都會產生錯誤或警告，人工作編譯器的工做，沒有必要。若是出錯，大部分錯誤都是邏輯錯誤，這種類型標註幫不了什麼忙。

• 適用面窄，跟不上發展

該命名法對於C++引入模板容器來講就是災難。引入的容器、迭代器等等不少，單字母已經沒法表示，姑且用vec表示std::vector，那該模板類的實例std::vector<int>怎麼表示？
即便能表示，std::vector<std::vector<std::vector<int>>>這個又怎麼表示？

世上沒有解決不了的問題，上述的問題確定也是能夠解決的，只要制定相應的規則便可。問題是：這個成本能獲得多大的回報。對於系統匈牙利命名法來講，是沒有必要的。

請關注個人公衆號哦。