匈牙利命名法

匈牙利命名法計算器程序設計中的一種命名規則，用這種方法命名的變數顯示了其數據類型。匈牙利命名法有兩種：系統匈牙利命名法和匈牙利應用命名法。

匈牙利命名法被設計成語言獨立的，并且首次在BCPL語言中被大量使用。由于BCPL只有機器字這一種數據類型，因此這種語言本身無法幫助程序設計師來記住變量的類型。匈牙利命名法通過明確每個變量的數據類型來解決這個問題。

在匈牙利命名法中，一個變量名由一個或多個小寫字母開始，這些字母有助于記憶變量的類型和用處，緊跟著的就是程序設計師選擇的任何名稱。這個后半部分的首字母可以大寫以區別前面的類型指示字母（參見駝峰式大小寫）。

目錄 1 歷史 2 系統匈牙利命名法與匈牙利應用命名法 3 示例 4 系統匈牙利命名法的優點 5 匈牙利系統命名法的缺點 6 注釋和參考 7 內部連結 8 外部連結

原始的匈牙利命名法，現在被稱為匈牙利應用命名法，由1972年至1981年在施樂帕洛阿爾托研究中心工作的程序設計師查爾斯·西蒙尼發明。此人后來成了微軟的總設計師。

這種命名法其實是對于西蒙尼祖籍的一種諷刺。匈牙利人名和大多數其它歐洲人名相比是反過來的，即姓氏在名字的前面。舉個例子，英語化的名字"Charles Simonyi"在匈牙利語中原本是"Simonyi Károly"。同樣的，在匈牙利命名法中，類型名在實際變量名前，而不是像大多數歐洲的Smalltalk那樣，類型放在變量名后，例如aPoint和lastPoint。后者在西蒙尼任職于施樂帕洛阿爾托研究中心時期非常流行。這種命名法可能也是受到了一種叫做波蘭式的不相關的概念的啟發。

匈牙利命名法這個叫法被許多人記住是因為難發音的輔音字符串有點像一些東歐語言中輔音豐富的拼寫方式，盡管實際上匈牙利語是屬于 芬蘭-烏戈爾語族，而不像斯拉夫語族那樣元音豐富。舉例來說，零結束字符串的前綴"sz"實際上就是匈牙利字母表中的一個合體字母（參看德語中的?）。

系統匈牙利命名法與匈牙利應用命名法

系統命名法與應用命名法的區別在于前綴的目的。

在系統匈牙利命名法中，前綴代表了變量的實際數據類型。例如：

• lAccountNum?: 變數是一個長整型 ("l");
• arru8NumberList?: 變量是一個無符號8位整型數組 ("arru8");
• szName?: 變量是一個零結束字符串 ("sz")，這是西蒙尼最開始建議的前綴之一。

匈牙利應用命名法不表示實際數據類型，而是給出了變量目的的提示，或者說它代表了什么。

• rwPosition?: 變量代表一個行 ("rw")。
• usName?: 變量代表一個非安全字符串 ("us")，需要在使用前處理。
• strName?: 變量代表一個包含名字的字符串("str")但是沒有指明這個字符串是如何實現的。

西蒙尼建議的大多數前綴都是自然語義的，但不是所有。下面幾個是來自原始論文的： ^[1]

• pX是指向另一個X類型的指針，這包含非常少的語義信息。
• d是一個前綴表示兩個值的區別，例如，dY可能代表一個圖形沿Y軸的距離，而一個僅僅叫做y的變量可能是一個絕對坐標。這完全是自然語義的。
• sz是一個無結束或零結束的字符串。在C中，這包含一些語義信息，因為它不是很明確一個char*類型的變量是一個指向單個字符的指針，還是一個字符數組，亦或是一個零結束字符串。
• w標記一個變量是一個字。這基本上沒有包含什么語義信息，因此大概會被當成是系統命名法。
• b標記了一個字節，和w對比可能有一些語義信息，因為C語言中，只有字節大小的數據是char型的，因此這些有時候被用來保存數值。這個前綴也許可以明確某個變量保存的是應該被看作是字母（或更一般的字符）的數值還是一個數字。

由于這種命名法通常使用小寫字母開頭用來助記，但是并沒有對助記符本身作規定。有幾種被廣泛使用的習慣（見下面的示例），但是任意字母組合都可以被使用，只要它們在代碼主體中保持一致就可以了。

在使用匈牙利應用命名法的代碼中有時候也可能包含系統匈牙利命名法，即在描述被單獨以類型方式定義的變量時使用。

示例

• bBusy?: 布爾型
• cApples?: 項目計數
• dwLightYears?: 雙字（系統）
• fBusy?: 布爾型（標記）
• nSize?: 整型（系統）或計數（應用程序）
• iSize?: 整型（系統）或索引（應用程序）
• fpPrice: 浮點數
• dbPi?: 雙精度浮點數（系統）
• pFoo?: 指針
• rgStudents?: 數組或范圍
• szLastName?: 零結束字符串
• u32Identifier?: 無符號32位整型（系統）
• stTime?: 時鐘結構
• fnFunction?: 函數名

對于指針和數組來說，它們實際上并不是數據類型，因此通常在助記符后面跟著實際元素的類型。

• pszOwner?: 指向零結束字符串的指針
• rgfpBalances?: 浮點值的數組

由于匈牙利命名法可以被應用在任何程序語言和環境中，因此被微軟廣泛用在C語言中，特別是在Microsoft Windows里。由此一來，許多常見的匈牙利命名法的結構都和Windows緊密相關：

• hwndFoo?: 窗口句柄
• lpszBar?: 指向零結束字符串的長指針

這種命名法又是在C++中被擴展而包含變量的作用域，由一個下劃線隔開：

• g_nWheels?: 全局命名空間的成員，整型
• m_nWheels?: 結構體/類成員，整型

系統匈牙利命名法的優點

（其中一些只適用于系統匈牙利命名法） 支持者聲稱匈牙利命名法的好處包括：^[1]

• 從名字中就可以看出變量的類型
• 擁有類似語義的多個變量可以在一個代碼塊中使用：dwWidth, iWidth, fWidth, dWidth
• 變量名在僅僅知道他們的類型時可以被輕易記住
• 可以使變量名更加一致
• 決定一個變量名的時候可以更機械化，更快
• 不合適的類型轉換和操作可以在閱讀代碼的時候被檢測出來
• 在那些數字被當作字符串處理的基于字符串的語言中非常有用（例如Tcl）
• 在匈牙利應用命名法中，變量名確保不會犯以下錯誤：

heightWindow = window.getWidth()

• 在使用動態類型語言或完全無類型的語言編程時，關于類型的修飾可以更簡化。這種語言一般不包含類型修飾（或者可選），因此唯一可以看出哪些類型是被允許的只有名字本身、文檔以及通過閱讀代碼來明白它們在做什么。在這些語言中，包含對于變量類型的指示可能會有助于程序設計師。就像上面提到的，匈牙利命名法擴展了這樣的語言（BCPL）。
• 在包含許多全局對象的復雜程序中（VB/Delphi Forms），擁有一個基本的前綴命名法可以簡化在編輯器中查找組件的工作。按btn<Ctrl-Space>可以使編輯器彈出一個Button對象的列表。

匈牙利系統命名法的缺點

批評者認為：

• 匈牙利命名法在編譯器做類型檢查時是多余的。 一個提供類型檢查的語言在確定一個變量與其類型一致時，比人眼僅僅檢查變量的用法與變量名一致要強大的多。
• 一些現代的集成開發環境，如Visual Studio在需要時可以顯示變量類型，并且自動標記不匹配的類型。使用這種命名法完全沒有必要。
• 匈牙利命名法在被用作代表多個屬性的時候會造成困惑，如 a_crszkvc30LastNameCol：一個常量引用參數，保存了一個varchar(30)類型的數據庫列LastName的內容，而這列又是這個表的主鍵的一部分。
• 在代碼更改后可能造成不一致。如果一個變量的類型改變了，不是變量名的修飾與新的類型不一致，就是變量名必須被改變。
• 由于變量名和類型捆綁在一起，因此不利于代碼的移植。一個典型的眾所周之的例子就是WPARAM類型，以及在許多Windows系統函數聲明中使用的wParam參數。它原本是一個16位的類型，但是在后來的操作系統中被改成了32位或64位，但仍保留原來的名字（它實際的基礎類型是UINT_PTR，即一個大小足夠保存一個指針的無符號整型）。
• 大多數時候，看到一個變量就意味著知道了它的類型。但是，如果你不知道一個變量是干什么的，知道了它的類型也沒什么幫助。

.NET Framework，微軟新的軟件開發平臺，除了接口類型一般不適用匈牙利命名法。在.NET中，習慣在接口類型前放一個I（例如Windows Forms中的IButtonControl界面。）.NET Framework指導方針建議程序設計師不要用匈牙利命名法，但是沒有指明不要用系統匈牙利命名法還是匈牙利應用命名法，或者是兩者都不要用。^[2] 與此對比，Java的標準庫中連接口類型也不加前綴。^[3]

?

總結

以上是生活随笔為你收集整理的匈牙利命名法（指导）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。