1、匈牙利命名法 匈牙利命名法是一种编程时的命名规范。基本原则是：变量名属性类型对象描述，其中每一对象的名称都要求有明确含义，可以取对象名字全称或名字的一部分。命名要基于容易记忆容易理解的原则。保证名字的连贯性是非常重要的。 据说这种命名法是一位叫 Charles Simonyi 的匈牙利程序员发明的，后来他在微软呆了几年，于是这种命名法就通过微软的各种产品和文档资料向世界传播开了。现在，大部分程序员不管自己使用什么软件进行开发，或多或少都使用了这种命名法。这种命名法的出发点是把量名变按：属性+类型+对象描述的顺序组合起来，以使程序员作变量时对变量的类型和其它属性有直观的了解，下面是 HN 变量命
2、名规范，其中也有一些是我个人的偏向： 匈牙利命名法-属性部分 全局变量 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 是
3、变量对象描述，表示窗口，所以 hwnd 表示窗口句柄； pfnEatApple ： pfn 是类型描述，表示指向函数的指针， EatApple 是变量对象描述，所以它表示 指向 EatApple 函数的函数指针变量。 g_cch ： g_ 是属性描述，表示全局变量，c 和 ch 分别是计数类型和字符类型，一起表示变量类 型，这里忽略了对象描述，所以它表示一个对字符进行计数的全局变量。 上面就是 HN 命名法的一般规则。 小结:匈牙利命名法 匈牙利命名法 MFC、句柄、控件及结构的命名规范 Windows 类型 样本变量 MFC 类 样本变量 HWND hWnd； CWnd* pWnd； HDL
4、G 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； CStat
5、e* 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，CPrintIn
6、fo 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 lp
7、sz LPSTR 32 位字符串指针 lpszName lpsz LPCSTR 32 位常量字符串指针 lpszName lpsz LPCTSTR 如果_UNICODE 定义，则为 32 位常量字符串指针 lpszName h handle Windows 对象句柄 hWnd lpfn callback 指向 CALLBACK 函数的远指针 前缀 符号类型 实例 范围 IDR_ 不同类型的多个资源共享标识 IDR_MAIINFRAME 10x6FFF IDD_ 对话框资源 IDD_SPELL_CHECK 10x6FFF HIDD_ 对话框资源的 Help 上下文 HIDD_SPELL_CHEC
8、K 0x200010x26FF IDB_ 位图资源 IDB_COMPANY_LOGO 10x6FFF IDC_ 光标资源 IDC_PENCIL 10x6FFF IDI_ 图标资源 IDI_NOTEPAD 10x6FFF ID_ 来自菜单项或工具栏的命令 ID_TOOLS_SPELLING 0x80000xDFFF HID_ 命令 Help 上下文 HID_TOOLS_SPELLING 0x180000x1DFFF IDP_ 消息框提示 IDP_INVALID_PARTNO 80xDEEF HIDP_ 消息框 Help 上下文 HIDP_INVALID_PARTNO 0x300080x3DEFF
9、 IDS_ 串资源 IDS_COPYRIGHT 10x7EEF IDC_ 对话框内的控件 IDC_RECALC 80xDEEF Microsoft MFC 宏命名规范 名称 类型 _AFXDLL 唯一的动态连接库（Dynamic Link Library，DLL）版本 _ALPHA 仅编译 DEC Alpha 处理器 _DEBUG 包括诊断的调试版本 _MBCS 编译多字节字符集 _UNICODE 在一个应用程序中打开 Unicode AFXAPI MFC 提供的函数 CALLBACK 通过指针回调的函数 库标识符命名法 标识符 值和含义 u ANSI（N ）或 Unicode（U） d 调试
10、或发行：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 位置，如果正在编写
11、一个具有导出 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
12、声明 wParam 所使用的类型，wParam 是窗口程序的第三个参数 LPVOID 一般指针类型，与（void *）相同，可以用来代替 LPSTR-抨击匈牙利命名法匈牙利命名法是一种编程时的命名规范。命名规范是程序书写规范中最重要也是最富争议的地方，自古乃兵家必争之地。命名规范有何用？四个字：名正言顺。用二分法，命名规范分为好的命名规范和坏的命名规范，也就是说名正言顺的命名规范和名不正言不顺的命名规范。好的舞鞋是让舞者感觉不到其存在的舞鞋，坏的舞鞋是让舞者带着镣铐起舞。一个坏的命名规范具有的破坏力比一个好的命名规范具有的创造力要大得多。本文要证明的是：匈牙利命名法是一个坏的命名规范。本文的作
13、用范围为静态强类型编程语言。本文的分析范本为 C 语言和 C+语言。下文中的匈法为匈牙利命名法的简称。一 匈牙利命名法的成本匈法的表现形式为给变量名附加上类型名前缀，例如：nFoo,szFoo,pFoo,cpFoo 分别表示整型变量，字符串型变量，指针型变量和常指针型变量。可以看出，匈法将变量的类型信息从单一地点（声明变量处）复制到了多个地点（使用变量处） ，这是冗余法。冗余法的成本之一是要维护副本的一致性。这个成本在编写和维护代码的过程中需要改变变量的类型时付出。冗余法的成本之二是占用了额外的空间。一个优秀的书写者会自觉地遵从一个法则：代码最小组织单位的长度以 30 个自然行以下为宜，如果超
14、过 50 行就应该重新组织。一个变量的书写空间会给这一法则添加不必要的难度。二 匈牙利命名法的收益这里要证明匈牙利命名法的收益是含糊的，无法预期的。范本 1：strcpy(pstrFoo,pcstrFoo2) Vs strcpy(foo,foo2)匈法在这里有什么收益呢？我看不到。没有一个程序员会承认自己不知道 strcpy 函数的参数类型吧。范本 2：unknown_function(nFoo) Vs unknown_function(foo)匈法在这里有什么收益呢？我看不到。对于一个不知道确定类型的函数，程序员应该去查看该函数的文档，这是一种成本。使用匈法的唯一好处是看代码的人知道这个函数
15、要求一个整型参数，这又有什么用处呢？函数是一种接口，参数的类型仅仅是接口中的一小部分。诸如函数的功能、出口信息、线程安全性、异常安全性、参数合法性等重要信息还是必须查阅文档。范本 3：nFoo=nBar Vs foo=bar匈法在这里有什么收益呢？我看不到。使用匈法的唯一好处是看代码的人知道这里发生了一个整型变量的复制动作，听起来没什么问题，可以安心睡大觉了。如果他看到的是 nFoo=szBar，可能会从美梦中惊醒。且慢，事情真的会是这样吗？我想首先被惊醒的应该是编译器。另一方面，nFoo=nBar 只是在语法上合法而已，看代码的人真正关心的是语义的合法性，匈法对此毫无帮助。另一方面，一个优秀
16、的书写者会自觉地遵从一个法则：代码最小组织单位中的临时变量以一两个为宜，如果超过三个就应该重新组织。结合前述第一个法则，可以得出这样的结论：易于理解的代码本身就应该是易于理解的，这是代码的内建高质量。好的命名规范对内建高质量的助益相当有限，而坏的命名规范对内建高质量的损害比人们想象的要大。三 匈牙利命名法的实施这里要证明匈牙利命名法在 C 语言是难以实施的，在 C+语言中是无法实施的。从逻辑上讲，对匈法的收益做出否定的结论以后，再来论证匈法的可行性，是画蛇添足。不过有鉴于小马哥曾让已射杀之敌死灰复燃，我还是再踏上一支脚为妙。前面讲过，匈法是类型系统的冗余，所以实施匈法的关键是我们是否能够精确地
17、对类型系统进行复制。这取决于类型系统的复杂性。先来看看 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 语言
18、并没有非常严格地区分不同的指针类型。下面开始表演：pausfoo 表示联合结构 foo 数组指针？ppp 表示指针的指针的指针？噩梦还没有结束，再来看看类型系统更阿为丰富的 C+语言：1.class：如果说 C 语言中的 struct 还可以用 stru 搪塞过去的话，不要梦想用 cls 来搪塞 C+中的 class。严格地讲，class 根本就并不是一个类型，而是创造类型的工具，在 C+中，语言内置类型的数量和 class 创造的用户自定义类型的数量相比完全可以忽略不计。stdvectorFoo 表示标准库向量类型变量 Foo？疯狂的念头。2.命名空间：boostfilesystemiter
19、atorFoo，表示 boost 空间 filesystem 子空间遍历目录类型变量 Foo？程序员要崩溃了。3.模板：你记得 std:map类型的确切名字吗？我是记不得了，好像超过 255 个字符，还是饶了我吧。4.模板参数：template const T& max(const T& a, const T& b, BinaryPredicate comp) 聪明的你，请用匈法为 T命名。上帝在发笑。5.类型修饰：static,extern,mutable,register,volatile,const,short,long,unsigned 噩梦加上修饰是什么？还是噩梦。附录：MFC、句柄
20、、控件及结构的命名规范 Windows 类型样本变量MFC 类样本变量HWNDhWnd；CWnd*pWnd；HDLGhDlg；CDialog*pDlg；HDChDC；CDC*pDC；HGDIOBJhGdiObj；CGdiObject*pGdiObj；HPENhPen；CPen*pPen；HBRUSHhBrush；CBrush*pBrush；HFONT hFont； CFont*pFont；HBITMAP hBitmap；CBitmap*pBitmap；HPALETTE hPaltte；CPalette*pPalette；HRGN hRgn；CRgn*pRgn；HMENU hMenu；CMenu
21、*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，CPrintInfom_成员变
22、量m_pDoc，m_nCustomers变量命名规范 前缀类型描述实例chchar8 位字符chGradech TCHAR如果_UNICODE 定义，则为 16 位字符chNamebBOOL布尔值bEnablen int整型（其大小依赖于操作系统）nLengthn UINT 无符号值（其大小依赖于操作系统）nHeightw WORD 16 位无符号值wPosl LONG 32 位有符号整型lOffsetdw DWORD 32 位无符号整型 dwRangep * 指针pDoclp FAR* 远指针 lpszNamelpsz LPSTR 32 位字符串指针lpszNamelpsz LPCSTR 3
23、2 位常量字符串指针lpszNamelpsz LPCTSTR 如果_UNICODE 定义，则为 32 位常量字符串指针lpszNameh handle Windows 对象句柄hWndlpfn callback指向 CALLBACK 函数的远指针 ?-抨击匈牙利命名法匈牙利命名法是一种编程时的命名规范。命名规范是程序书写规范中最重要也是最富争议的地方，自古乃兵家必争之地。命名规范有何用？四个字：名正言顺。用二分法，命名规范分为好的命名规范和坏的命名规范，也就是说名正言顺的命名规范和名不正言不顺的命名规范。好的舞鞋是让舞者感觉不到其存在的舞鞋，坏的舞鞋是让舞者带着镣铐起舞。一个坏的命名规范具有的
24、破坏力比一个好的命名规范具有的创造力要大得多。本文要证明的是：匈牙利命名法是一个坏的命名规范。本文的作用范围为静态强类型编程语言。本文的分析范本为 C 语言和 C+语言。下文中的匈法为匈牙利命名法的简称。一 匈牙利命名法的成本匈法的表现形式为给变量名附加上类型名前缀，例如：nFoo,szFoo,pFoo,cpFoo 分别表示整型变量，字符串型变量，指针型变量和常指针型变量。可以看出，匈法将变量的类型信息从单一地点（声明变量处）复制到了多个地点（使用变量处），这是冗余法。冗余法的成本之一是要维护副本的一致性。这个成本在编写和维护代码的过程中需要改变变量的类型时付出。冗余法的成本之二是占用了额外的
25、空间。一个优秀的书写者会自觉地遵从一个法则：代码最小组织单位的长度以 30 个自然行以下为宜，如果超过 50 行就应该重新组织。一个变量的书写空间会给这一法则添加不必要的难度。二 匈牙利命名法的收益这里要证明匈牙利命名法的收益是含糊的，无法预期的。范本 1：strcpy(pstrFoo,pcstrFoo2) Vs strcpy(foo,foo2)匈法在这里有什么收益呢？我看不到。没有一个程序员会承认自己不知道 strcpy 函数的参数类型吧。范本 2：unknown_function(nFoo) Vs unknown_function(foo)匈法在这里有什么收益呢？我看不到。对于一个不知道确
26、定类型的函数，程序员应该去查看该函数的文档，这是一种成本。使用匈法的唯一好处是看代码的人知道这个函数要求一个整型参数，这又有什么用处呢？函数是一种接口，参数的类型仅仅是接口中的一小部分。诸如函数的功能、出口信息、线程安全性、异常安全性、参数合法性等重要信息还是必须查阅文档。范本 3：nFoo=nBar Vs foo=bar匈法在这里有什么收益呢？我看不到。使用匈法的唯一好处是看代码的人知道这里发生了一个整型变量的复制动作，听起来没什么问题，可以安心睡大觉了。如果他看到的是 nFoo=szBar，可能会从美梦中惊醒。且慢，事情真的会是这样吗？我想首先被惊醒的应该是编译器。另一方面，nFoo=nB
27、ar 只是在语法上合法而已，看代码的人真正关心的是语义的合法性，匈法对此毫无帮助。另一方面，一个优秀的书写者会自觉地遵从一个法则：代码最小组织单位中的临时变量以一两个为宜，如果超过三个就应该重新组织。结合前述第一个法则，可以得出这样的结论：易于理解的代码本身就应该是易于理解的，这是代码的内建高质量。好的命名规范对内建高质量的助益相当有限，而坏的命名规范对内建高质量的损害比人们想象的要大。三 匈牙利命名法的实施这里要证明匈牙利命名法在 C 语言是难以实施的，在 C+语言中是无法实施的。从逻辑上讲，对匈法的收益做出否定的结论以后，再来论证匈法的可行性，是画蛇添足。不过有鉴于小马哥曾让已射杀之敌死灰
28、复燃，我还是再踏上一支脚为妙。前面讲过，匈法是类型系统的冗余，所以实施匈法的关键是我们是否能够精确地对类型系统进行复制。这取决于类型系统的复杂性。先来看看 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.特殊类型：poin
29、ter。pointer 在理论上应该是组合类型，但是在 C 语言中可以认为是内置类型，因为C 语言并没有非常严格地区分不同的指针类型。下面开始表演：pausfoo 表示联合结构 foo 数组指针？ppp表示指针的指针的指针？噩梦还没有结束，再来看看类型系统更阿为丰富的 C+语言：1.class：如果说 C 语言中的 struct 还可以用 stru 搪塞过去的话，不要梦想用 cls 来搪塞 C+中的 class。严格地讲，class 根本就并不是一个类型，而是创造类型的工具，在 C+中，语言内置类型的数量和 class 创造的用户自定义类型的数量相比完全可以忽略不计。stdvectorFoo
30、表示标准库向量类型变量 Foo？疯狂的念头。2.命名空间：boostfilesystemiteratorFoo，表示 boost 空间 filesystem 子空间遍历目录类型变量 Foo？程序员要崩溃了。3.模板：你记得 std:map类型的确切名字吗？我是记不得了，好像超过 255个字符，还是饶了我吧。4.模板参数：template const T& max(const T& a, const T& b, BinaryPredicate comp) 聪明的你，请用匈法为 T 命名。上帝在发笑。5.类型修饰：static,extern,mutable,register,volatile,const,short,long,unsigned 噩梦加上修饰是什么？还是噩梦。你愿意做镣铐上的舞者吗？
