这才是真正的“匈牙利命名法”



 

从刚进大学开始学习 C 语言，就听说了实际开发中会用到的各种变量命名方法，例如常见的匈牙利命名法、骆驼命名法、Pascal 命名法等。

后来自己真正开始用 C/C++ 写程序，开始使用匈牙利命名法，总觉得十分别扭。好好的变量名 name，严格按照命名规则，非得在前面加类型前缀，改写成 lpszName。

如今的 IDE 都会自动检查变量类型，而且类型错误在编译时也比较容易发现，在变量名前面强制加上类型信息实在不知道有什么意义。

 

直到无意中在《More Joel on Software》[1] 这本书第 23 章看到匈牙利命名法作者——Charles Simonyi 的本意。

 

1. 应用型匈牙利命名法——鲜为人知的正统

Simonyi 的匈牙利命名法的原型在微软公司内部最初被叫做“应用型匈牙利命名法”（Apps Hungarian），因为它是在“应用程序部”（Applications Division）中使用的，也就是用在 Word 和 Excel 身上。在 Excel 的源码中，你可以看到大量的 rw 和 col 。

使用这种“应用型匈牙利命名法”，我们可以在看到变量后很快理解其含义，并很容易发现代码中的问题。

例如在代码中看到 xl = cb，

xl 表示“相对于页面的横坐标”，horizontal coordinates relatives to the layout；cb 表示“字节个数”，count of bytes

显然是有问题的，虽然 xl 和 cb 都是整数，但是这二者之间的赋值基本一定会导致 bug。

 

2. 系统型匈牙利命名法——广为流传的冒牌货

然而，一定程度上由于 Simonyi 自己在编写文档时，用了“type”这个词，而不是“kind”，于是被人误以为 Simonyi 指的是数据类型。尽管 Simonyi 很详细、很准确地解释了他所说的“type”到底是什么意思。可惜于事无补，危害已经酿成了。悲剧的结果就是产生了我们现在熟悉的“系统型匈牙利命名法”（System Hungarian）。

还是上面的例子，改用“系统型匈牙利命名法”以后，可以改成 nWidth = nCount，看起来好像还不错哈～

bug 就是这样隐藏起来的。

 

“应用型匈牙利命名法”的前缀是非常有用的、有含义的，比如：

• “ix” 表示数组的索引值（index）
• “c” 表示一个计数器（count）
• “d” 表示两个数量之间的差（difference），“dx” 就可以表示宽度

 “系统性匈牙利命名法”的前缀就差远了，比如

• “l” 表示长整型（long）
• “ul” 表示无符号长整型（unsigned long）
• “dw” 表示双精度值（double word），这实际上也是一个无符号的长整型

这种差别虽然细微，但是完全误解了 Simonyi 的意图和做法。“系统型匈牙利命名法”传播的又远又广，在 Windows 编程文档中，它是标准的变量命名法。难怪很多人都觉得匈牙利命名法很奇怪、很别扭。

 

参考文章：

[1] Joel Spolsky 著，阮一峰 译，中文名《软件随想录》http://book.douban.com/subject/4163938/

[2] 匈牙利命名法的衰落和建议 http://blog.kingsamchen.com/archives/618#comment-1310

[3] lifeicd的读书笔记

历史

据说这种命名法是一位叫 Charles Simonyi 的 匈牙利程序员发明的，后来他在 微软呆了几年，于是这种命名法就通过微软的各种产品和文档资料向世界传播开了。大部分 程序员不管自己使用什么 软件进行开发，或多或少都使用了这种命名法。这种命名法的出发点是把 变量名按：属性+类型+对象描述的顺序组合起来，以使程序员作变量时对变量的类型和其它属性有直观的了解，下面是HN变量命名规范。

2变量属性

属性部分：

g_ 全局变量

c_ 　 常量

m_ 　c++类 成员变量

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

3举例

hwnd ： h 是类型描述，表示句柄， wnd 是 变量对象描述，表示窗口，所以 hwnd 表示 窗口句柄；

pfnEatApple ： pfn 是类型描述，表示指向函数的 指针， EatApple 是 变量对象描述，所以它表示指向 EatApple 函数的函数 指针变量。

g_cch ： g_ 是属性描述，表示 全局变量，c 和 ch 分别是计数类型和 字符类型，一起表示变量类型，这里忽略了对象描述，所以它表示一个对字符进行计数的全局变量。

上面就是HN命名法的一般规则。

4总结

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

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

5反对声音

匈牙利命名法是一种编程时的命名规范。命名规范是程序书写规范中最重要也是最富争议的地方，自古乃 兵家必争之地。命名规范有何用？四个字：名正言顺。用二分法，命名规范分为好的命名规范和坏的命名规范，也就是说名正言顺的命名规范和 名不正言不顺的命名规范。好的舞鞋是让舞者感觉不到其存在的舞鞋，坏的舞鞋是让舞者带着镣铐起舞。一个坏的命名规范具有的破坏力比一个好的命名规范具有的创造力要大得多。

有人认为， 匈牙利命名法是一个坏的命名规范。举例说明。以 静态强类型编程语言为例，分析范本为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语言并没有非常严格地区分不同的 指针类型。

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) 这一条来用 匈牙利命名法命名，难度极大。

5.类型修饰：static,extern,mutable,register,volatile,const,short,long,unsigned 加上类型修饰，更是难上加难。

匈牙利命名法有其优点但也有缺点，这就需要在使用中扬长避短，合理应用它。