匈牙利命名法規則

1. 什麼是匈牙利命名法有什麼規則

匈牙利命名法

匈牙利命名法是一種編程時的命名規范。基本原則是：變數名＝屬性＋類型＋對象描述，其中每一對象的名稱都要求有明確含義，可以取對象名字全稱或名字的一部分。命名要基於容易記憶容易理解的原則。保證名字的連貫性是非常重要的。

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

這種命名技術是由一位能乾的Microsoft程序員查爾斯·西蒙尼(Charles Simonyi) 提出的，他出生在匈牙利。在 Microsoft 公司中和他一起工作的人被教會使用這種約定。這對他們來說一切都很正常。但對那些 Simonyi 領導的項目組之外的人來說卻感到很奇特，他們認為這是死板的表達方式，甚至說帶有這樣奇怪的外觀是因為它是用匈牙利文寫的。從此這種命名方式就被叫做匈牙利命名法。

據說這種命名法是一位叫 Charles Simonyi 的匈牙利程序員發明的，後來他在微軟呆了幾年，於是
這種命名法就通過微軟的各種產品和文檔資料向世界傳播開了。現在，大部分程序員不管自己使用
什麼軟體進行開發，或多或少都使用了這種命名法。這種命名法的出發點是把量名變按：屬性+類型
+對象 描述的順序組合起來，以使程序員作變數時對變數的類型和其它屬性有直觀的了解，下面
是HN變數命名規范，其中也有一些是我個人的偏向：

屬性部分
全局變數
g_
常量
c_
c++類成員變數
m_
靜態變數
s_

類型部分
指針
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 表示窗口句柄；
pfnEatApple ： pfn 是類型描述，表示指向函數的指針， EatApple 是變數對象描述，所以它表示
指向 EatApple 函數的函數指針變數。
g_cch ： g_ 是屬性描述，表示全局變數，c 和 ch 分別是計數類型和字元類型，一起表示變數類
型，這里忽略了對象描述，所以它表示一個對字元進行計數的全局變數。
上面就是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
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

2. 變數命名是否符合匈牙利命名法前綴如何判斷拜託了各位 謝謝

匈牙利命名法是一種編程時的命名規范。基本原則是：變數名＝屬性＋類型＋對象描述，其中每一對象的名稱都要求有明確含義，可以取對象名字全稱或名字的一部分。命名要基於容易記憶容易理解的原則。保證名字的連貫性是非常重要的。 舉例來說，表單的名稱為form，那麼在匈牙利命名法中可以簡寫為frm，則當表單變數名稱為 Switchboard時，變數全稱應該為 frmSwitchboard。這樣可以很容易從變數名看出Switchboard是一個表單，同樣，如果此變數類型為標簽，那麼就應命名成 lblSwitchboard。可以看出，匈牙利命名法非常便於記憶，而且使變數名非常清晰易懂，這樣，增強了代碼的可讀性，方便各程序員之間相互交流代 碼。 據說這種命名法是一位叫 Charles Simonyi 的匈牙利程序員發明的，後來他在微軟呆了幾年，於是這種命名法就通過微軟的各種產品和文檔資料向世界傳播開了。現在，大部分程序員不管自己使用什麼軟體進 行開發，或多或少都使用了這種命名法。這種命名法的出發點是把變數名按：屬性+類型+對象描述的順序組合起來，以使程序員作變數時對變數的類型和其它屬性 有直觀的了解，下面是HN變數命名規范，其中也有一些是我個人的偏向： 屬性部分 全局變數 g_ 常量 c_ c++類成員變數 m_ 靜態變數 s_ 類型部分 指針 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 表示窗口句柄； pfnEatApple ： pfn 是類型描述，表示指向函數的指針， EatApple 是變數對象描述，所以它表示 指向EatApple 函數的函數指針變數。 g_cch ： g_ 是屬性描述，表示全局變數，c 和 ch 分別是計數類型和字元類型，一起表示變數類 型，這里忽略了對象描述，所以它表示一個對字元進行計數的全局變數。 上面就是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 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 -------------------------------------------------------------------------------- 抨擊匈牙利命名法 匈牙利命名法是一種編程時的命名規范。命名規范是程序書寫規范中最重要也是最富爭議的地方，自 古乃兵家必爭之地。命名規范有何用？四個字：名正言順。用二分法，命名規范分為好的命名規范和壞的命名規范，也就是說名正言順的命名規范和名不正言不順的 命名規范。好的舞鞋是讓舞者感覺不到其存在的舞鞋，壞的舞鞋是讓舞者帶著鐐銬起舞。一個壞的命名規范具有的破壞力比一個好的命名規范具有的創造力要大得 多。 本文要證明的是：匈牙利命名法是一個壞的命名規范。本文的作用范圍為靜態強類型編程語言。本文的分析範本為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 噩夢加上修飾是什麼？還是噩夢。

3. 微軟匈牙利命名法是怎麼回事啊

命名規范
命名應盡量使用匈牙利命名法，變數名或函數名中使用大寫字元來專區分各個屬部分，以便於記憶和閱讀。如bPatchMinute, DeleteDirInfo()。全局(包括類中的)變數用長名字，局部變數用短名字。
類成員變數前一般應加上m_，全局變數加上g_，僅與本模塊有關的變數加上l_,緊接著是變數的類型。
整型： n,i
長整型: l
無符號整型： u
無符號長整型：dw
字元： ch
布爾量： b
浮點數: f
雙精度浮點: d
字元串： str,lpsz,sz,p,lp,ac,
指針： p
位元組指針： pb
無符號指針： pv
字元指針： lpsz
整型指針： lpn
文件指針： fp
如：
m_nTotalNum,m_strPath,m_bRcving,m_fPrice,g_lOpenDate,g_dwCardNo,lpszNameStr,
lpnSysDoomType,uMsgID,m_pProgress

4. 根據 匈牙利 命名法，合法的標識符是什麼

匈牙利命名法

匈牙利命名法是一種編程時的命名規范。基本原則是：變數名＝屬性＋類型＋對象描述，其中每一對象的名稱都要求有明確含義，可以取對象名字全稱或名字的一部分。命名要基於容易記憶容易理解的原則。保證名字的連貫性是非常重要的。

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

這種命名技術是由一位能乾的Microsoft程序員查爾斯·西蒙尼(Charles Simonyi) 提出的，他出生在匈牙利。在 Microsoft 公司中和他一起工作的人被教會使用這種約定。這對他們來說一切都很正常。但對那些 Simonyi 領導的項目組之外的人來說卻感到很奇特，他們認為這是死板的表達方式，甚至說帶有這樣奇怪的外觀是因為它是用匈牙利文寫的。從此這種命名方式就被叫做匈牙利命名法。

5. 除了匈牙利命名法則還有什麼命名法則

參看林銳《軟體工程》
匈牙利命名法是Microsoft公司倡導的 [Maguire 1993]，雖然很煩瑣，但用習慣了也就成了自然版。沒有人權強迫你採用何種命名法，但有一點應該做到：自己的程序命名必須一致。

以下是我編程時採用的命名約定：

（1）宏定義用大寫字母加下劃線表示，如MAX_LENGTH；

（2）函數用大寫字母開頭的單片語合而成，如SetName, GetName ；

（3）指針變數加前綴p，如 *pNode ；

（4）BOOL 變數加前綴b，如 bFlag ；

（5）int 變數加前綴i，如 iWidth ；

（6）float 變數加前綴f，如 fWidth ；

（7）double變數加前綴d，如 dWidth ；

（8）字元串變數加前綴str，如 strName ；

（9）枚舉變數加前綴e，如 eDrawMode ；

（10）類的成員變數加前綴m_，如 m_strName, m_iWidth ；

對於 int, float, double 型的變數，如果變數名的含義十分明顯，則不加前綴，避免煩瑣。如用於循環的int型變數 i,j,k ；float 型的三維坐標（x,y,z）等。

6. 匈牙利命名法的總結

MFC、句柄、控制項及結構的命名規范：
Windows類型 樣本變數；類 樣本變數
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

7. 說起來寫java的時候用匈牙利命名法多麼

匈牙利命名法不是很多
目前java用駝峰式命名法比較多
Java駝峰式命名法：
1、變數名必須為有意義的單詞
2、變數名如果只有一個單詞，則小寫
3、如果有2個以及多個單詞，則從第二個單詞開始首字母大寫

8. 匈牙利命名法的舉例

一種命名方法,常用於資料庫，用"_"隔開
例如：sys_user_info