基本介紹
- 中文名：匈牙利命名法
- 基本原則：變數名=屬性+類型+對象描述
- 命名：容易記憶容易理解的原則
- 原則：保證名字的連貫性
簡介,例子,歷史,變數屬性,舉例,總結,反對聲音,成本,收益,實施,
簡介
例子
舉例來說，表單的名稱為form，那么在匈牙利命名法中可以簡寫為frm，則當表單變數名稱為Switchboard時，變數全稱應該為 frmSwitchboard。這樣可以很容易從變數名看出Switchboard是一個表單，同樣，如果此變數類型為標籤，那么就應命名成 lblSwitchboard。可以看出，匈牙利命名法非常便於記憶，而且使變數名非常清晰易懂，這樣，增強了代碼的可讀性，方便各程式設計師之間相互交流代碼。
Charles Simonyi歷史
據說這種命名法是一位叫 Charles Simonyi 的匈牙利程式設計師發明的，後來他在微軟待了幾年，於是這種命名法就通過微軟的各種產品和文檔資料向世界傳播開了。大部分程式設計師不管自己使用什麼軟體進行開發，或多或少都使用了這種命名法。這種命名法的出發點是把變數名按：屬性+類型+對象描述的順序組合起來，以使程式設計師作變數時對變數的類型和其它屬性有直觀的了解，下面是HN變數命名規範。
變數屬性
屬性部分：
g_ 全局變數
c_ 常量
m_ c++類成員變數
s_ 靜態變數
類型部分：
數組 a
指針 p
函式 fn
無效 v
句柄 h
長整型 l
布爾 b
浮點型（有時也指檔案） f
雙字 dw
字元串 sz
短整型 n
雙精度浮點 d
計數 c（通常用cnt）
字元 ch（通常用c）
整型 i（通常用n）
位元組 by
字 w
實型 r
無符號 u
描述部分：
最大 Max
最小 Min
初始化 Init
臨時變數 T（或Temp）
源對象 Src
目的對象 Dest
舉例
hwnd ： h 是類型描述，表示句柄， wnd 是變數對象描述，表示視窗，所以 hwnd 表示視窗句柄；
上面就是HN命名法的一般規則。
總結
MFC、句柄、控制項及結構的命名規範：
Windows類型 樣本變數；MFC類 樣本變數
HWND hWnd； CWnd* pWnd；
HDLG hDlg； CDialog* pDlg；
HDC hDC； CDC* pDC；
HGDIOBJ hGdiObj； CGdiObject* pGdiObj；
HPEN hPen； CPen* pPen；
HBRUSH hBrush； CBrush* pBrush；
HFONT hFont； CFont* pFont；
HBITMAP hBitmap； CBitmap* pBitmap；
HPALETTE hPaltte； CPalette* pPalette；
HRGN hRgn； CRgn* pRgn；
HMENU hMenu； CMenu* pMenu；
HWND hCtl； CState* pState；
HWND hCtl； CButton* pButton；
HWND hCtl； CEdit* pEdit；
HWND hCtl； CListBox* pListBox；
HWND hCtl； CComboBox* pComboBox；
HWND hCtl； CScrollBar* pScrollBar；
HSZ hszStr； CString pStr；
POINT pt； CPoint pt；
SIZE size； CSize size；
RECT rect； CRect rect；
一般前綴命名規範：
前綴&類型&實例
C 類或結構 CDocument，CPrintInfo
m_ 成員變數 m_pDoc，m_nCustomers
變數命名規範：
前綴&類型&描述&實例
ch char 8位字元 chGrade
ch TCHAR 如果_UNICODE定義，則為16位字元 chName
b BOOL 布爾值 bEnable
n int 整型（其大小依賴於作業系統） nLength
u UINT 無符號值（其大小依賴於作業系統） uHeight
w WORD 16位無符號值 wPos
l LONG 32位有符號整型 lOffset
dw DWORD 32位無符號整型 dwRange
p * 指針 pDoc
lp FAR* 遠指針 lpszName
lpsz LPSTR 32位字元串指針 lpszName
lpsz LPCSTR 32位常量字元串指針 lpszName
lpsz LPCTSTR 如果_UNICODE定義，則為32位常量字元串指針 lpszName
h handle Windows對象句柄 hWnd
lpfn callback 指向CALLBACK函式的遠指針
前綴_符號類型：
前綴_符號類型實例&範圍
IDR_ 不同類型的多個資源共享標識 IDR_MAIINFRAME 1～0x6FFF
IDD_ 對話框資源 IDD_SPELL_CHECK 1～0x6FFF
HIDD_ 對話框資源的Help上下文 HIDD_SPELL_CHECK 0x20001～0x26FF
IDB_ 點陣圖資源 IDB_COMPANY_LOGO 1～0x6FFF
IDC_ 游標資源 IDC_PENCIL 1～0x6FFF
IDI_ 圖示資源 IDI_NOTEPAD 1～0x6FFF
ID_ 來自選單項或工具列的命令 ID_TOOLS_SPELLING 0x8000～0xDFFF
HID_ 命令Help上下文 HID_TOOLS_SPELLING 0x18000～0x1DFFF
IDP_ 訊息框提示 IDP_INVALID_PARTNO 8～0xDEEF
HIDP_ 訊息框Help上下文 HIDP_INVALID_PARTNO 0x30008～0x3DEFF
IDS_ 串資源 IDS_COPYRIGHT 1～0x7EEF
IDC_ 對話框內的控制項 IDC_RECALC 8～0xDEEF
Microsoft MFC宏命名規範：
名稱&類型
_AFXDLL 唯一的動態連線庫（Dynamic Link Library，DLL）版本
_ALPHA 僅編譯DEC Alpha處理器
_DEBUG 包括診斷的調試版本
_MBCS 編譯多位元組字元集
_UNICODE 在一個應用程式中打開Unicode
AFXAPI MFC提供的函式
CALLBACK 通過指針回調的函式
庫標識符命名法：
標識符&值和含義
u ANSI（N）或Unicode（U）
d 調試或發行：D = 調試；忽略標識符為發行。
靜態庫版本命名規範：
庫&描述
NAFXCWD.LIB 調試版本：MFC靜態連線庫
NAFXCW.LIB 發行版本：MFC靜態連線庫
UAFXCWD.LIB 調試版本：具有Unicode支持的MFC靜態連線庫
UAFXCW.LIB 發行版本：具有Unicode支持的MFC靜態連線庫
動態連線庫命名規範：
名稱&類型
_AFXDLL 唯一的動態連線庫（DLL）版本
WINAPI Windows所提供的函式
Windows.h中新的命名規範：
類型&定義描述
WINAPI 使用在API聲明中的FAR PASCAL位置，如果正在編寫一個具有導出API人口點的DLL，則可以在自己的API中使用該類型
CALLBACK 使用在應用程式回叫例程，如視窗和對話框過程中的FAR PASCAL的位置
LPCSTR 與LPSTR相同，只是LPCSTR用於唯讀串指針，其定義類似（const char FAR*）
UINT 可移植的無符號整型類型，其大小由主機環境決定（對於Windows NT和Windows 9x為32位）；它是unsigned int的同義詞
LRESULT 視窗程式返回值的類型
LPARAM 聲明lParam所使用的類型，lParam是視窗程式的第四個參數
WPARAM 聲明wParam所使用的類型，wParam是視窗程式的第三個參數
LPVOID 一般指針類型，與（void *）相同，可以用來代替LPSTR
反對聲音
匈牙利命名法是一種編程時的命名規範。命名規範是程式書寫規範中最重要也是最富爭議的地方，自古乃兵家必爭之地。命名規範有何用？四個字：名正言順。用二分法，命名規範分為好的命名規範和壞的命名規範，也就是說名正言順的命名規範和名不正言不順的命名規範。好的舞鞋是讓舞者感覺不到其存在的舞鞋，壞的舞鞋是讓舞者帶著鐐銬起舞。一個壞的命名規範具有的破壞力比一個好的命名規範具有的創造力要大得多。
有人認為，匈牙利命名法是一個壞的命名規範。舉例說明。以靜態強類型程式語言為例，分析範本為C語言和C++語言。下文中的匈法為匈牙利命名法的簡稱。
成本
匈法的表現形式為給變數名附加上類型名前綴，例如：nFoo,szFoo,pFoo,cpFoo分別表示整型變數，字元串型變數，指針型變數和常指針型變數。可以看出，匈法將變數的類型信息從單一地點（聲明變數處）複製到了多個地點（使用變數處），這是冗餘法。冗餘法的成本之一是要維護副本的一致性。這個成本在編寫和維護代碼的過程中需要改變變數的類型時付出。冗餘法的成本之二是占用了額外的空間。一個優秀的書寫者會自覺地遵從一個法則：代碼最小組織單位的長度以30個自然行以下為宜，如果超過50行就應該重新組織。一個變數的書寫空間會給這一法則添加不必要的難度。
收益
匈牙利命名法的收益是含糊的，無法預期的。
範本1：strcpy(pstrFoo,pcstrFoo2) Vs strcpy(foo,foo2)
沒有一個程式設計師會承認自己不知道strcpy函式的參數類型，所以收益為零。
範本2：unknown_function(nFoo) Vs unknown_function(foo)
收益仍是沒有的。對於一個不知道確定類型的函式，程式設計師應該去查看該函式的文檔，這是一種成本。使用匈法的唯一好處是看代碼的人知道這個函式要求一個整型參數，這沒有任何用處。函式是一種接口，參數的類型僅僅是接口中的一小部分。諸如函式的功能、出口信息、執行緒安全性、異常安全性、參數合法性等重要信息還是必須查閱文檔。
範本3：nFoo=nBar Vs foo=bar
使用匈法的唯一好處是看代碼的人知道這裡發生了一個整型變數的複製動作，聽起來沒什麼問題，可以安心了。如果他看到的是nFoo=szBar，就沒辦法放心下來了。但是事情並非如此。首先出現問題的應該是編譯器。另一方面，nFoo=nBar只是在語法上合法而已，看代碼的人真正關心的是語義的合法性，匈法對此毫無幫助。另一方面，一個優秀的書寫者會自覺地遵從一個法則：代碼最小組織單位中的臨時變數以一兩個為宜，如果超過三個就應該重新組織。結合前述第一個法則，可以得出這樣的結論：易於理解的代碼本身就應該是易於理解的，這是代碼的內建高質量。好的命名規範對內建高質量的助益相當有限，而壞的命名規範對內建高質量的損害比人們想像的要大。
實施
匈牙利命名法在C語言是難以實施的，在C++語言中是無法實施的。
匈法是類型系統的冗餘，所以實施匈法的關鍵是我們是否能夠精確地對類型系統進行複製。這取決於類型系統的複雜性。
C語言：
1.內置類型：int,char,float,double 複製為 n,ch,f,d？好像沒有什麼問題。但是void應該怎么表示，匈法做不到。
2.組合類型：array,union,enum,struct 複製為 a,u,e,s？並不方便。
這裡的難點不是為主類型取名，而是為副類型取名。an表示整型數組？sfoo,sbar表示結構foo，結構bar？ausfoo表示聯合結構foo數組？非常冗繁。
3.特殊類型：pointer。pointer在理論上應該是組合類型，但是在C語言中可以認為是內置類型，因為C語言並沒有非常嚴格地區分不同的指針類型。
C++語言：
1.class：如果說C語言中的struct還可以用stru搪塞過去的話，不要夢想用cls來搪塞C++中的class。嚴格地講，class根本就並不是一個類型，而是創造類型的工具，在C++中，語言內置類型的數量和class創造的用戶自定義類型的數量相比完全可以忽略不計。stdvectorFoo表示標準庫向量類型變數Foo，是不合乎邏輯的。
2.命名空間：boostfilesystemiteratorFoo，表示boost空間filesystem子空間遍歷目錄類型變數Foo，依舊不可行。
3.模板：std::map<std::string,std::string>類型的確切名字是什麼，已經超過了255個字元。
4.模板參數：template <class T, class BinaryPredicate>const T& max(const T& a, const T& b, BinaryPredicate comp) 這一條來用匈牙利命名法命名，難度極大。
5.類型修飾：static,extern,mutable,register,volatile,const,short,long,unsigned 加上類型修飾，更是難上加難。
匈牙利命名法有其優點但也有缺點，這就需要在使用中揚長避短，合理套用它。
