匈牙利命名法
匈牙利命名法是一種編程時的命名規(guī)范。基本原則是:變量名=屬性+類型+對象描述,其中每一對象的名稱都要求有明確含義,可以取對象名字全稱或名字的一部分。命名要基于容易記憶容易理解的原則。保證名字的連貫性是非常重要的。
舉例來說,表單的名稱為form,那么在匈牙利命名法中可以簡寫為frm,則當(dāng)表單變量名稱為 Switchboard時,變量全稱應(yīng)該為 frmSwitchboard。這樣可以很容易從變量名看出Switchboard是一個表單,同樣,如果此變量類型為標(biāo)簽,那么就應(yīng)命名成 lblSwitchboard。可以看出,匈牙利命名法非常便于記憶,而且使變量名非常清晰易懂,這樣,增強(qiáng)了代碼的可讀性,方便各程序員之間相互交流代 碼。
據(jù)說這種命名法是一位叫 Charles Simonyi 的匈牙利程序員發(fā)明的,后來他在微軟呆了幾年,于是這種命名法就通過微軟的各種產(chǎn)品和文檔資料向世界傳播開了。現(xiàn)在,大部分程序員不管自己使用什么軟件進(jìn) 行開發(fā),或多或少都使用了這種命名法。這種命名法的出發(fā)點(diǎn)是把變量名按:屬性+類型+對象描述的順序組合起來,以使程序員作變量時對變量的類型和其它屬性 有直觀的了解,下面是HN變量命名規(guī)范,其中也有一些是我個人的偏向:
屬性部分
全局變量
g_
常量
c_
c++類成員變量
m_
靜態(tài)變量
s_
類型部分
指針
p
函數(shù)
fn
無效
v
句柄
h
長整型
l
布爾
b
浮點(diǎn)型(有時也指文件)
f
雙字
dw
字符串
sz
短整型
n
雙精度浮點(diǎn)
d
計數(shù)
c(通常用cnt)
字符
ch(通常用c)
整型
i(通常用n)
字節(jié)
by
字
w
實(shí)型
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ù)類型和字符類型,一起表示變量類
型,這里忽略了對象描述,所以它表示一個對字符進(jìn)行計數(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ī)范 前綴 類型 實(shí)例
C 類或結(jié)構(gòu) CDocument,CPrintInfo
m_ 成員變量 m_pDoc,m_nCustomers
變量命名規(guī)范 前綴 類型 描述 實(shí)例
ch char 8位字符 chGrade
ch TCHAR 如果_UNICODE定義,則為16位字符 chName
b BOOL 布爾值 bEnable
n int 整型(其大小依賴于操作系統(tǒng)) nLength
n UINT 無符號值(其大小依賴于操作系統(tǒng)) nHeight
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)指針
前綴 符號類型 實(shí)例 范圍
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_ 來自菜單項(xiàng)或工具欄的命令 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ā)行。
靜態(tài)庫版本命名規(guī)范 庫 描述
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)連接庫
動態(tài)連接庫命名規(guī)范 名稱 類型
_AFXDLL 唯一的動態(tài)連接庫(DLL)版本
WINAPI Windows所提供的函數(shù)
Windows.h中新的命名規(guī)范 類型 定義描述
WINAPI 使用在API聲明中的FAR PASCAL位置,如果正在編寫一個具有導(dǎo)出API人口點(diǎn)的DLL,則可以在自己的API中使用該類型
CALLBACK 使用在應(yīng)用程序回叫例程,如窗口和對話框過程中的FAR PASCAL的位置
LPCSTR 與LPSTR相同,只是LPCSTR用于只讀串指針,其定義類似(const char FAR*)
UINT 可移植的無符號整型類型,其大小由主機(jī)環(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)造力要大得 多。
本文要證明的是:匈牙利命名法是一個壞的命名規(guī)范。本文的作用范圍為靜態(tài)強(qiáng)類型編程語言。本文的分析范本為C語言和C++語言。下文中的匈法為匈牙利命名法的簡稱。
一 匈牙利命名法的成本
匈法的表現(xiàn)形式為給變量名附加上類型名前綴,例 如:nFoo,szFoo,pFoo,cpFoo分別表示整型變量,字符串型變量,指針型變量和常指針型變量。可以看出,匈法將變量的類型信息從單一地點(diǎn) (聲明變量處)復(fù)制到了多個地點(diǎn)(使用變量處),這是冗余法。冗余法的成本之一是要維護(hù)副本的一致性。這個成本在編寫和維護(hù)代碼的過程中需要改變變量的類 型時付出。冗余法的成本之二是占用了額外的空間。一個優(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,可能會從美夢中驚醒。且慢,事情真的會是這樣嗎?我想首先被驚 醒的應(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ì)量的損害比人們想象的要大。
三 匈牙利命名法的實(shí)施
這里要證明匈牙利命名法在C語言是難以實(shí)施的,在C++語言中是無法實(shí)施的。從邏輯上講,對匈法的收益做出否定的結(jié)論以后,再來論證匈法的可行性,是畫蛇添足。不過有鑒于小馬哥曾讓已射殺之?dāng)乘阑覐?fù)燃,我還是再踏上一支腳為妙。
前面講過,匈法是類型系統(tǒng)的冗余,所以實(shí)施匈法的關(guān)鍵是我們是否能夠精確地對類型系統(tǒng)進(jìn)行復(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?好像比較別扭。
這里的難點(diǎn)不是為主類型取名,而是為副類型取名。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)置類型,因?yàn)镃語言并沒有非常嚴(yán)格地區(qū)分不同的指針類型。下面開始表演:pausfoo表示聯(lián)合結(jié)構(gòu)foo數(shù)組指針?ppp表示指針的指針的指針?
噩夢還沒有結(jié)束,再來看看類型系統(tǒng)更阿為豐富的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<std::string,std::string>類型的確切名字嗎?我是記不得了,好像超過255個字符,還是饒了我吧。
4.模板參數(shù):template <class T, class BinaryPredicate>const T& max(const T& a, const T& b, BinaryPredicate comp) 聰明的你,請用匈法為T命名。上帝在發(fā)笑。
5.類型修飾:static,extern,mutable,register,volatile,const,short,long,unsigned 噩夢加上修飾是什么?還是噩夢。
匈牙利命名法是一種編程時的命名規(guī)范。基本原則是:變量名=屬性+類型+對象描述,其中每一對象的名稱都要求有明確含義,可以取對象名字全稱或名字的一部分。命名要基于容易記憶容易理解的原則。保證名字的連貫性是非常重要的。
舉例來說,表單的名稱為form,那么在匈牙利命名法中可以簡寫為frm,則當(dāng)表單變量名稱為 Switchboard時,變量全稱應(yīng)該為 frmSwitchboard。這樣可以很容易從變量名看出Switchboard是一個表單,同樣,如果此變量類型為標(biāo)簽,那么就應(yīng)命名成 lblSwitchboard。可以看出,匈牙利命名法非常便于記憶,而且使變量名非常清晰易懂,這樣,增強(qiáng)了代碼的可讀性,方便各程序員之間相互交流代 碼。
據(jù)說這種命名法是一位叫 Charles Simonyi 的匈牙利程序員發(fā)明的,后來他在微軟呆了幾年,于是這種命名法就通過微軟的各種產(chǎn)品和文檔資料向世界傳播開了。現(xiàn)在,大部分程序員不管自己使用什么軟件進(jìn) 行開發(fā),或多或少都使用了這種命名法。這種命名法的出發(fā)點(diǎn)是把變量名按:屬性+類型+對象描述的順序組合起來,以使程序員作變量時對變量的類型和其它屬性 有直觀的了解,下面是HN變量命名規(guī)范,其中也有一些是我個人的偏向:
屬性部分
全局變量
g_
常量
c_
c++類成員變量
m_
靜態(tài)變量
s_
類型部分
指針
p
函數(shù)
fn
無效
v
句柄
h
長整型
l
布爾
b
浮點(diǎn)型(有時也指文件)
f
雙字
dw
字符串
sz
短整型
n
雙精度浮點(diǎn)
d
計數(shù)
c(通常用cnt)
字符
ch(通常用c)
整型
i(通常用n)
字節(jié)
by
字
w
實(shí)型
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ù)類型和字符類型,一起表示變量類
型,這里忽略了對象描述,所以它表示一個對字符進(jìn)行計數(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ī)范 前綴 類型 實(shí)例
C 類或結(jié)構(gòu) CDocument,CPrintInfo
m_ 成員變量 m_pDoc,m_nCustomers
變量命名規(guī)范 前綴 類型 描述 實(shí)例
ch char 8位字符 chGrade
ch TCHAR 如果_UNICODE定義,則為16位字符 chName
b BOOL 布爾值 bEnable
n int 整型(其大小依賴于操作系統(tǒng)) nLength
n UINT 無符號值(其大小依賴于操作系統(tǒng)) nHeight
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)指針
前綴 符號類型 實(shí)例 范圍
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_ 來自菜單項(xiàng)或工具欄的命令 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ā)行。
靜態(tài)庫版本命名規(guī)范 庫 描述
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)連接庫
動態(tài)連接庫命名規(guī)范 名稱 類型
_AFXDLL 唯一的動態(tài)連接庫(DLL)版本
WINAPI Windows所提供的函數(shù)
Windows.h中新的命名規(guī)范 類型 定義描述
WINAPI 使用在API聲明中的FAR PASCAL位置,如果正在編寫一個具有導(dǎo)出API人口點(diǎn)的DLL,則可以在自己的API中使用該類型
CALLBACK 使用在應(yīng)用程序回叫例程,如窗口和對話框過程中的FAR PASCAL的位置
LPCSTR 與LPSTR相同,只是LPCSTR用于只讀串指針,其定義類似(const char FAR*)
UINT 可移植的無符號整型類型,其大小由主機(jī)環(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)造力要大得 多。
本文要證明的是:匈牙利命名法是一個壞的命名規(guī)范。本文的作用范圍為靜態(tài)強(qiáng)類型編程語言。本文的分析范本為C語言和C++語言。下文中的匈法為匈牙利命名法的簡稱。
一 匈牙利命名法的成本
匈法的表現(xiàn)形式為給變量名附加上類型名前綴,例 如:nFoo,szFoo,pFoo,cpFoo分別表示整型變量,字符串型變量,指針型變量和常指針型變量。可以看出,匈法將變量的類型信息從單一地點(diǎn) (聲明變量處)復(fù)制到了多個地點(diǎn)(使用變量處),這是冗余法。冗余法的成本之一是要維護(hù)副本的一致性。這個成本在編寫和維護(hù)代碼的過程中需要改變變量的類 型時付出。冗余法的成本之二是占用了額外的空間。一個優(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,可能會從美夢中驚醒。且慢,事情真的會是這樣嗎?我想首先被驚 醒的應(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ì)量的損害比人們想象的要大。
三 匈牙利命名法的實(shí)施
這里要證明匈牙利命名法在C語言是難以實(shí)施的,在C++語言中是無法實(shí)施的。從邏輯上講,對匈法的收益做出否定的結(jié)論以后,再來論證匈法的可行性,是畫蛇添足。不過有鑒于小馬哥曾讓已射殺之?dāng)乘阑覐?fù)燃,我還是再踏上一支腳為妙。
前面講過,匈法是類型系統(tǒng)的冗余,所以實(shí)施匈法的關(guān)鍵是我們是否能夠精確地對類型系統(tǒng)進(jìn)行復(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?好像比較別扭。
這里的難點(diǎn)不是為主類型取名,而是為副類型取名。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)置類型,因?yàn)镃語言并沒有非常嚴(yán)格地區(qū)分不同的指針類型。下面開始表演:pausfoo表示聯(lián)合結(jié)構(gòu)foo數(shù)組指針?ppp表示指針的指針的指針?
噩夢還沒有結(jié)束,再來看看類型系統(tǒng)更阿為豐富的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<std::string,std::string>類型的確切名字嗎?我是記不得了,好像超過255個字符,還是饒了我吧。
4.模板參數(shù):template <class T, class BinaryPredicate>const T& max(const T& a, const T& b, BinaryPredicate comp) 聰明的你,請用匈法為T命名。上帝在發(fā)笑。
5.類型修飾:static,extern,mutable,register,volatile,const,short,long,unsigned 噩夢加上修飾是什么?還是噩夢。
文章來源:http://blog.163.com/ccbobo_cat/blog/static/32099462200931411226261