匈牙利命名法???????
本人覺得匈牙利命名法確實是一件規范編程的好東東，可是苦于部分名字難記，見了好幾遍也不見得認識，難道一定要全盤按照匈牙利法來命名嗎？恐怕不見得。
文后有某君卻也走了極端，全盤否定匈牙利命名法，貼出來以供參考，探討。???????????????????????????????????
按照MS方式編程：匈牙利符號表示法?
匈牙利符號表示法包括許多與下列命名有關的約定：?
（1）變量?
（2）函數?
（3）類型和常量?
（4）類?
（5）參數?
匈牙利符號表示法的前綴代碼指導說明書：?
**************************************************************************?
前綴????????????????????????? 數據類型（基本類型）?
C???????????????????????????? 字符?
BY??????????????????????????? 字節?
N???????????????????????????? 短整數和整數（表示一個數）?
I???????????????????????????? 整數?
X，Y????????????????????????? 短整數（通常用于X坐標和Y坐標）?
CX，CY??????????????????????? 短整數（通常用于表示X和Y的長度，C表示計數）?
B???????????????????????????? 布爾型?
W???????????????????????????? UINT（無符號數）和WORD（無符號字）?
L???????????????????????????? LONG（長整數）?
DW??????????????????????????? DWORD（無符號長整數）?
FN??????????????????????????? 函數指針?
S???????????????????????????? 串?
SZ，STR?????????????????????? 以0字節終止的字符串?
LP??????????????????????????? 32位長整數指針?
H???????????????????????????? 編號（常用于表示Windows對象）?
MSG?????????????????????????? 消息?
**************************************************************************?
變量的命名：?
應用匈牙利表示法，變量可用上表中的前綴代碼來表示。另外，當一個變量是由一個或幾個子名構成時
，每一個子名都要以大寫字母開頭。下?
面是幾個例子：?
char *szfileName;????????? // a nulla terminated string:以0終止的字符串?
int *lpidate;?????????????? // a 32-bit pointer to an int:指向一個整型變量的32位的長指針?
Bool,bSemaphore;????????????? //a boolean value?
WORD dwMaxCount???????????? // a 32-bit unsigned WORD?
盡管我們了解一個函數的局部變量沒有說明，但是也有個別表示全局變量必須要以 g_ 開頭：?
int g_iXPos;?????????????? // a global x-position?
int g_iTimer;????????????? // a global y-position?
char *g_szString?????????? //a global NULL terminated string?
函數的命名：?
函數和變量的命名方式相同，但是沒有前綴，換句話說，子名的第一個字母要大寫。下面是幾個例子：
int PlotPixel(int ix,int iy,int ic);?
void *MemScan(char *szString);?
而且，下劃線是非法的。例如，下面的函數名表示是無效的匈牙利表示法：?
int Get_Pixel(int ix,int iy);?
類型和常量的命名：?
所有的類型和常量都是大寫字母，但名字中可以允許有下劃線。如：?
const LONG NUM_SECTORS=100;????????? // a C++ style constant?
#define MAX_CELLS 64;??????????????? // a C style constant?
#define POWERUNIT 100;?????????????? // a C style constant?
typedef unsigned char UCHAR;???????? // a user defined type?
類的命名?
類命名的約定可能要麻煩一點。但我也看到有很多人在使用這個約定，并獨立地進行補充。不管怎么說
，所有C++的類必須以大寫C為前綴，類?
名字的每一個子名的第一個字母都必須大寫：?
class CVector???????? // the chinese mean of vector is 矢量?
{?
public?
CVector();?
{ix=iy=iz=imagnitude=0;}??? //the chinese mean of magnitude is 大小?
CVector(int x, int y, int z)??
{ix=x;iy=y;iz=z;}?
......?
private:?
int ix,iy,iz;//the position of the vector?
int imagnitude; //the magnitude of the vector?
......?
}?
參數的命名?
函數的參數命名和標準變量命名的約定相同。但也不總是如此。如：?
UCHAR GetPixel(int x,int y);?
這種情況下，更準確的匈牙利的函數原型是：?
UCHAR GetPixel(int ix,int iy);
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
n? UINT? 無符號值（其大小依賴于操作系統） nHeight
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
?
抨擊匈牙利命名法
作者:bbao
抨擊匈牙利命名法
匈牙利命名法是一種編程時的命名規范。命名規范是程序書寫規范中最重要也是最富爭議的地方，自古乃兵家必爭之地。命名規范有何用？四個字：名正言順。用二分法，命名規范分為好的命名規范和壞的命名規范，也就是說名正言順的命名規范和名不正言不順的命名規范。好的舞鞋是讓舞者感覺不到其存在的舞鞋，壞的舞鞋是讓舞者帶著鐐銬起舞。一個壞的命名規范具有的破壞力比一個好的命名規范具有的創造力要大得多。
本文要證明的是：匈牙利命名法是一個壞的命名規范。本文的作用范圍為靜態強類型編程語言。本文的分析范本為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語言并沒有非常嚴格地區分不同的指針類型。下面開始表演：pausfoo表示聯合結構foo數組指針？ppp表示指針的指針的指針？
噩夢還沒有結束，再來看看類型系統更阿為豐富的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) 聰明的你，請用匈法為T命名。上帝在發笑。
5.類型修飾：static,extern,mutable,register,volatile,const,short,long,unsigned 噩夢加上修飾是什么？還是噩夢。
你愿意做鐐銬上的舞者嗎？
posted on 2006-11-07 21:32
哈哈 閱讀(810)
評論(0) 編輯 收藏 引用