匈牙利命名法来源
MFC、句柄、控件及结构的命名规范
ＶＢ Ｐｒｅｆｉｘ命名规范
在编程时，变量、函数的命名是一个极其重要的问题。好的命名方法使变量易于记忆且程序可读性大大提高。Microsoft采用匈牙利命名法来命名Windows API函数和变量。匈牙利命名法是由Microsoft的著名开发人员、Excel的主要设计者查尔斯·西蒙尼在他的博士论文中提出来的，由于西蒙尼的国籍是匈牙利，所以这种命名法叫匈牙利命名法。
匈牙利命名法为C标识符的命名定义了一种非常标准化的方式，这种命名方式是以两条规则为基础：
1.标识符的名字以一个或者多个小写字母开头，用这些字母来指定数据类型。
2.在标识符内，前缀以后就是一个或者多个第一个字母大写的单词，这些单词清楚地指出了源代码内那个对象的用途。比如，m_szStudentName表示一个学生名字的类成员变量，数据类型是字符串型。
附录：
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函数的远指针
?
--------------------------------------------------------------------------------
抨击匈牙利命名法
匈牙利命名法是一种编程时的命名规范。命名规范是程序书写规范中最重要也是最富争议的地方，自古乃兵家必争之地。命名规范有何用？四个字：名正言顺。用二分法，命名规范分为好的命名规范和坏的命名规范，也就是说名正言顺的命名规范和名不正言不顺的命名规范。好的舞鞋是让舞者感觉不到其存在的舞鞋，坏的舞鞋是让舞者带着镣铐起舞。一个坏的命名规范具有的破坏力比一个好的命名规范具有的创造力要大得多。
本文要证明的是：匈牙利命名法是一个坏的命名规范。本文的作用范围为静态强类型编程语言。本文的分析范本为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 噩梦加上修饰是什么？还是噩梦。
你愿意做镣铐上的舞者吗？
[返回] 计算机科学论坛 →
计算机技术与应用 → 『 C/C++编程思想 』 → 关于匈牙利命名法[转帖]
(订阅本版)
2005/12/19 18:46:00
新浪微博
关于匈牙利命名法[转帖]
