匈牙利命名法是一種編程時的命名規(guī)范?；驹瓌t是：變量名=屬性+類型+對象描述，其中每一對象的名稱都要求有明確含義，可以取對象名字全稱或名字的一部分。命名要基于容易記憶容易理解的原則。保證名字的連貫性是非常重要的。匈牙利命名法非常便于記憶，而且使變量名非常清晰易懂，增強了代碼的可讀性，方便各程序員之間相互交流代碼。

匈牙利命名法_匈牙利命名法 -簡介

例子

舉例來說，表單的名稱為form，那么在匈牙利命名法中可以簡寫為frm，則當(dāng)表單變量名稱為Switchboard時，變量全稱應(yīng)該為 frmSwitchboard。這樣可以很容易從變量名看出Switchboard是一個表單，同樣，如果此變量類型為標(biāo)簽，那么就應(yīng)命名成 lblSwitchboard?？梢钥闯?，匈牙利命名法非常便于記憶，而且使變量名非常清晰易懂，這樣，增強了代碼的可讀性，方便各程序員之間相互交流代碼。

歷史

據(jù)說這種命名法是一位叫 Charles Simonyi 的匈牙利程序員發(fā)明的，后來他在微軟呆了幾年，于是這種命名法就通過微軟的各種產(chǎn)品和文檔資料向世界傳播開了。大部分程序員不管自己使用什么軟件進行開發(fā)，或多或少都使用了這種命名法。這種命名法的出發(fā)點是把變量名按：屬性+類型+對象描述的順序組合起來，以使程序員作變量時對變量的類型和其它屬性有直觀的了解，下面是HN變量命名規(guī)范。

匈牙利命名法_匈牙利命名法 -變量屬性

屬性部分：

g_ 全局變量

c_ 常量

m_ c++類成員變量

s_ 靜態(tài)變量

類型部分：

數(shù)組 a

指針p

函數(shù)fn

無效v

句柄h

長整型l

布爾b

浮點型（有時也指文件）f

雙字 dw

字符串 sz

短整型 n

雙精度浮點d

計數(shù)c（通常用cnt）

字符ch（通常用c）

整型i（通常用n）

字節(jié)by

字w

實型r

無符號u

描述部分：

最大Max

最小Min

初始化Init

臨時變量T（或Temp）

源對象Src

目的對象Dest

匈牙利命名法_匈牙利命名法 -舉例

hwnd ： h 是類型描述，表示句柄， wnd 是變量對象描述，表示窗口，所以 hwnd 表示窗口句柄；

pfnEatApple ： pfn 是類型描述，表示指向函數(shù)的指針， EatApple 是變量對象描述，所以它表示指向 EatApple 函數(shù)的函數(shù)指針變量。

g_cch ： g_ 是屬性描述，表示全局變量，c 和 ch 分別是計數(shù)類型和字符類型，一起表示變量類型，這里忽略了對象描述，所以它表示一個對字符進行計數(shù)的全局變量。

上面就是HN命名法的一般規(guī)則。

匈牙利命名法_匈牙利命名法 -總結(jié)

MFC、句柄、控件及結(jié)構(gòu)的命名規(guī)范：

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；

一般前綴命名規(guī)范：

前綴&類型&實例

C 類或結(jié)構(gòu) CDocument，CPrintInfo

m_ 成員變量 m_pDoc，m_nCustomers

變量命名規(guī)范：

前綴&類型&描述&實例

ch char 8位字符 chGrade

ch TCHAR 如果_UNICODE定義，則為16位字符 chName

b BOOL 布爾值 bEnable

n int 整型（其大小依賴于操作系統(tǒng)） nLength

u UINT 無符號值（其大小依賴于操作系統(tǒng)） uHeight

w WORD 16位無符號值 wPos

l LONG 32位有符號整型 lOffset

dw DWORD 32位無符號整型 dwRange

p * 指針 pDoc

lp FAR* 遠(yuǎn)指針 lpszName

lpsz LPSTR 32位字符串指針 lpszName

lpsz LPCSTR 32位常量字符串指針 lpszName

lpsz LPCTSTR 如果_UNICODE定義，則為32位常量字符串指針 lpszName

h handle Windows對象句柄 hWnd

lpfn callback 指向CALLBACK函數(shù)的遠(yuǎn)指針

前綴_符號類型：

前綴_符號類型實例&范圍

IDR_ 不同類型的多個資源共享標(biāo)識 IDR_MAIINFRAME 1～0x6FFF

IDD_ 對話框資源 IDD_SPELL_CHECK 1～0x6FFF

HIDD_ 對話框資源的Help上下文 HIDD_SPELL_CHECK 0x20001～0x26FF

IDB_ 位圖資源 IDB_COMPANY_LOGO 1～0x6FFF

IDC_ 光標(biāo)資源 IDC_PENCIL 1～0x6FFF

IDI_ 圖標(biāo)資源 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_ 對話框內(nèi)的控件 IDC_RECALC 8～0xDEEF

Microsoft MFC宏命名規(guī)范：

名稱&類型

_AFXDLL 唯一的動態(tài)連接庫（Dynamic Link Library，DLL）版本

_ALPHA 僅編譯DEC Alpha處理器

_DEBUG 包括診斷的調(diào)試版本

_MBCS 編譯多字節(jié)字符集

_UNICODE 在一個應(yīng)用程序中打開Unicode

AFXAPI MFC提供的函數(shù)

CALLBACK 通過指針回調(diào)的函數(shù)

庫標(biāo)識符命名法：

標(biāo)識符&值和含義

u ANSI（N）或Unicode（U）

d 調(diào)試或發(fā)行：D = 調(diào)試；忽略標(biāo)識符為發(fā)行。

庫&描述

NAFXCWD.LIB 調(diào)試版本：MFC靜態(tài)連接庫

NAFXCW.LIB 發(fā)行版本：MFC靜態(tài)連接庫

UAFXCWD.LIB 調(diào)試版本：具有Unicode支持的MFC靜態(tài)連接庫

UAFXCW.LIB 發(fā)行版本：具有Unicode支持的MFC靜態(tài)連接庫

名稱&類型

_AFXDLL 唯一的動態(tài)連接庫（DLL）版本

WINAPI Windows所提供的函數(shù)

Windows.h中新的命名規(guī)范：

類型&定義描述

WINAPI 使用在API聲明中的FAR PASCAL位置，如果正在編寫一個具有導(dǎo)出API人口點的DLL，則可以在自己的API中使用該類型

CALLBACK 使用在應(yīng)用程序回叫例程，如窗口和對話框過程中的FAR PASCAL的位置

LPCSTR 與LPSTR相同，只是LPCSTR用于只讀串指針，其定義類似（const char FAR*）

UINT 可移植的無符號整型類型，其大小由主機環(huán)境決定（對于Windows NT和Windows 9x為32位）；它是unsigned int的同義詞

LRESULT 窗口程序返回值的類型

LPARAM 聲明lParam所使用的類型，lParam是窗口程序的第四個參數(shù)

WPARAM 聲明wParam所使用的類型，wParam是窗口程序的第三個參數(shù)

LPVOID 一般指針類型，與（void *）相同，可以用來代替LPSTR

匈牙利命名法_匈牙利命名法 -反對聲音

匈牙利命名法是一種編程時的命名規(guī)范。命名規(guī)范是程序書寫規(guī)范中最重要也是最富爭議的地方，自古乃兵家必爭之地。命名規(guī)范有何用？四個字：名正言順。用二分法，命名規(guī)范分為好的命名規(guī)范和壞的命名規(guī)范，也就是說名正言順的命名規(guī)范和名不正言不順的命名規(guī)范。好的舞鞋是讓舞者感覺不到其存在的舞鞋，壞的舞鞋是讓舞者帶著鐐銬起舞。一個壞的命名規(guī)范具有的破壞力比一個好的命名規(guī)范具有的創(chuàng)造力要大得多。

有人認(rèn)為，匈牙利命名法是一個壞的命名規(guī)范。舉例說明。以靜態(tài)強類型編程語言為例，分析范本為C語言和C++語言。下文中的匈法為匈牙利命名法的簡稱。

成本

匈法的表現(xiàn)形式為給變量名附加上類型名前綴，例如：nFoo,szFoo,pFoo,cpFoo分別表示整型變量，字符串型變量，指針型變量和常指針型變量?？梢钥闯觯俜▽⒆兞康念愋托畔膯我坏攸c（聲明變量處）復(fù)制到了多個地點（使用變量處），這是冗余法。冗余法的成本之一是要維護副本的一致性。這個成本在編寫和維護代碼的過程中需要改變變量的類型時付出。冗余法的成本之二是占用了額外的空間。一個優(yōu)秀的書寫者會自覺地遵從一個法則：代碼最小組織單位的長度以30個自然行以下為宜，如果超過50行就應(yīng)該重新組織。一個變量的書寫空間會給這一法則添加不必要的難度。

收益

匈牙利命名法的收益是含糊的，無法預(yù)期的。

范本1：strcpy(pstrFoo,pcstrFoo2) Vs strcpy(foo,foo2)

沒有一個程序員會承認(rèn)自己不知道strcpy函數(shù)的參數(shù)類型，所以收益為零。

范本2：unknown_function(nFoo) Vs unknown_function(foo)

收益仍是沒有的。對于一個不知道確定類型的函數(shù)，程序員應(yīng)該去查看該函數(shù)的文檔，這是一種成本。使用匈法的唯一好處是看代碼的人知道這個函數(shù)要求一個整型參數(shù)，這沒有任何用處。函數(shù)是一種接口，參數(shù)的類型僅僅是接口中的一小部分。諸如函數(shù)的功能、出口信息、線程安全性、異常安全性、參數(shù)合法性等重要信息還是必須查閱文檔。

范本3：nFoo=nBar Vs foo=bar

使用匈法的唯一好處是看代碼的人知道這里發(fā)生了一個整型變量的復(fù)制動作，聽起來沒什么問題，可以安心了。如果他看到的是nFoo=szBar，就沒辦法放心下來了。但是事情并非如此。首先出現(xiàn)問題的應(yīng)該是編譯器。另一方面，nFoo=nBar只是在語法上合法而已，看代碼的人真正關(guān)心的是語義的合法性，匈法對此毫無幫助。另一方面，一個優(yōu)秀的書寫者會自覺地遵從一個法則：代碼最小組織單位中的臨時變量以一兩個為宜，如果超過三個就應(yīng)該重新組織。結(jié)合前述第一個法則，可以得出這樣的結(jié)論：易于理解的代碼本身就應(yīng)該是易于理解的，這是代碼的內(nèi)建高質(zhì)量。好的命名規(guī)范對內(nèi)建高質(zhì)量的助益相當(dāng)有限，而壞的命名規(guī)范對內(nèi)建高質(zhì)量的損害比人們想象的要大。

實施

匈牙利命名法在C語言是難以實施的，在C++語言中是無法實施的。

匈法是類型系統(tǒng)的冗余，所以實施匈法的關(guān)鍵是我們是否能夠精確地對類型系統(tǒng)進行復(fù)制。這取決于類型系統(tǒng)的復(fù)雜性。

C語言：

1.內(nèi)置類型：int,char,float,double 復(fù)制為 n,ch,f,d？好像沒有什么問題。但是void應(yīng)該怎么表示，匈法做不到。

2.組合類型：array,union,enum,struct 復(fù)制為 a,u,e,s？并不方便。

這里的難點不是為主類型取名，而是為副類型取名。an表示整型數(shù)組？sfoo,sbar表示結(jié)構(gòu)foo，結(jié)構(gòu)bar？ausfoo表示聯(lián)合結(jié)構(gòu)foo數(shù)組？非常冗繁。

3.特殊類型：pointer。pointer在理論上應(yīng)該是組合類型，但是在C語言中可以認(rèn)為是內(nèi)置類型，因為C語言并沒有非常嚴(yán)格地區(qū)分不同的指針類型。

C++語言：

1.class：如果說C語言中的struct還可以用stru搪塞過去的話，不要夢想用cls來搪塞C++中的class。嚴(yán)格地講，class根本就并不是一個類型，而是創(chuàng)造類型的工具，在C++中，語言內(nèi)置類型的數(shù)量和class創(chuàng)造的用戶自定義類型的數(shù)量相比完全可以忽略不計。stdvectorFoo表示標(biāo)準(zhǔn)庫向量類型變量Foo，是不合乎邏輯的。

2.命名空間：boostfilesystemiteratorFoo，表示boost空間filesystem子空間遍歷目錄類型變量Foo，依舊不可行。

3.模板：std::map類型的確切名字是什么，已經(jīng)超過了255個字符。

4.模板參數(shù)：templateconst T& max(const T& a, const T& b, BinaryPredicate comp) 這一條來用匈牙利命名法命名，難度極大。

5.類型修飾：static,extern,mutable,register,volatile,const,short,long,unsigned 加上類型修飾，更是難上加難。

匈牙利命名法有其優(yōu)點但也有缺點，這就需要在使用中揚長避短，合理應(yīng)用它。

愛華網(wǎng)本文地址 » http://www.klfzs.com/a/8103320103/57181.html