几种常见的程序设计中命名规则

一、匈牙利命名法【Hungarian】： 广泛应用于象 Microsoft Windows 这样的环境中。 Windows 编程中用到的变量（还包括宏）的命名规则匈牙利命名法，这种命名技术是由一 位能干的 Microsoft 程序员查尔斯· 西蒙尼(Charles Simonyi) 提出的。 匈牙利命名法通过在变量名前面加上相应的小写字母的符号标识作为前缀， 标识出变量的作用域， 类型等。这些符号可以多个同时使用，顺序是先 m_（成员变量），再指针，再简单数据类型， 再其他。例如：m_lpszStr, 表示指向一个以 0 字符结尾的字符串的长指针成员变量。 匈牙利命名法关键是：标识符的名字以一个或者多个小写字母开头作为前缀；前缀之后的是 首字母大写的一个单词或多个单词组合，该单词要指明变量的用途。 匈牙利命名法中常用的小写字母的前缀： 前缀类型 a b by c cb cr cx,cy dw fn h i l lp m_ n np p s sz w 数组 (Array) 布尔值 (Boolean) 字节 (Byte) 有符号字符 (Char) 无符号字符 (Char Byte，没有多少人用) 颜色参考值 (ColorRef) 坐标差（长度 ShortInt） Double Word 函数 Handle（句柄） 整型 长整型 (Long Int) Long Pointer 类的成员 短整型 (Short Int) Near Pointer Pointer 字符串型 以 null 做结尾的字符串型 (String with Zero End) Word

二、骆驼命名法【camelCase】:

骆驼式命令法，正如它的名称所表示的那样，是指混合使用大小写字母来构成变量和函数 的名字。例如，下面是分别用骆驼式命名法和下划线法命名的同一个函数： printEmployeePaychecks()； print_employee_paychecks()； 第一个函数名使用知晌了骆驼式命名法——函数名中的每一个逻辑断点都有一个大写字母来标记； 第二个函数烂猛核名饥掘使用了下划线法----函数名中的每一个逻辑断点都有一个下划线来标记。 骆驼式命名法近年来越来越流行了，在许多新的函数库和 Microsoft Windows 这样的环境中，它使用得当相多。另一方面，下划线法是 c 出现后开始流行起来的，在 许多旧的程序和 UNIX 这样的环境中，它的使用非常普遍。

三、帕斯卡命名法【PascalCase】： 与骆驼命名法类似。只不过骆驼命名法是首字母小写，而帕斯卡命名法是首字母大写 如：public void DisplayInfo()string UserName二者都是采用了帕斯卡命名法. 【在 C#中，以帕斯卡命名法和骆驼命名法居多。 在 C#中,简单的变量一般用 camelCase 规则,而比较高级的命名使用 PascalCase。 如.net Framework 的公共字段及公共属性。】 简单说 MyData 是一个帕斯卡命名的示例。 myData 是一个骆驼命名法。 iMyData 是一个匈牙利命名法,小些说明了变量的类型或者用途。

匈牙利命名法

匈牙利命名法是一种编程时的命名规范。基本原则是：变量名＝属性＋类型＋对象描述，其中每一对象的名称都要求有明确含义，可以取对象名字全称或名字的一部分。命名要基于容易记忆容易理解的原则。保证名字的连贯性是非常重要的。

举例来说，表单的名称为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 噩梦加上修饰是什么？还是噩梦。百度地图

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

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

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

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

---