几年以前,Charles Simonyi(他后来成为微软的著名程序员)设计了一种以前缀为基础的命名方法,这种方法后来称为"匈牙利表示法"以记念他.他的思想是根据每个标识符所代表的含义给它一个前缀.微软后来采用了这个思想,给每个标识符一个前缀以说明它的数据类型.因此,整型变量的前缀是n,长整型变量是nl,字符型数组变量是ca,以及字符串(以空类型结尾的字符数组)以sz为前缀.这些名字可能会非常古怪.比如说:lpszFoo表示"Foo"是一个指向以空字符为结尾的字符串的长整型指针.
这种方法的优点是使人能够通过变量的名字来辨别变量的类型,而不比去查找它的定义.遗憾的是,这种方法不仅使变量名字非常绕口,而且使改变变量类型的工作变得十分艰巨.在Windows3.1中,整型变量为16为宽.如果我们在开始时采用了一个整型变量,但是在通过30---40个函数的计算之后,发现采用整型变量宽度不够,这时我们不仅要改变这个变量的类型,而且要改变这个变量在这30--40个函数中的名字.
因为不切实际,除了一些顽固的Windows程序员外已经没有人再使用"匈牙利表示法"了.毫无疑问,在某种场合它依然存在,但大部分人现在已经抛弃它了.一般而言,输入前缀是一种糟糕的想法,因为它把变量于其类型紧紧地绑在了一起.
对于30行以下的函数，匈牙利方法一般有优势。
尤其是对界面编程，有优势。
但对于有强烈的算法要求、尤其是有很多抽象类型的C++程序，匈牙利方法简直是一个灾难。
看你用在什么地方。
现在有了很好的IDE工具,如:VC,SourceInsight等.
选中变量,会自动提示告诉你它的声明和定义,这样
匈牙利命名法就没有很大的必要了.
无非就是为了程序可读性较好.
实际上良好的代码书写习惯比强制使用匈牙利命名法更重要.
系统性。整体性。可读性。分类要清楚。要有注释！
匈牙利命名法是微软推广的一种关于变量、函数、对象、前缀、宏定义等各种类型的符号的命名规范。匈牙利命名法的主要思想是：在变量和函数名中加入前缀以增进人们对程序的理解。它是由微软内部的一个匈牙利人发起使用的，结果它在微软内部逐渐流行起来，并且推广给了全世界的Windows开发人员。下面将介绍匈牙利命名法，后面的例子里也会尽量遵守它和上面的代码风格。还是那句话，并不是要求所有的读者都要去遵守，但是希望读者作为一个现代的软件开发人员都去遵守它。
| 前缀 | 类型 | 中文说明 |
| a | Array | 数组 |
| b | BOOL(int) | 布尔（整数） |
| by | Unsigned Char(Byte) | 无符号字符（字节） |
| c | Char | 字符（字节） |
| cb | Count of Bytes | 字节数 |
| cr | Color Reference Value | 颜色（参考）值 |
| cx | Count of x(Short) | x的集合（短整数） |
| f | Flags(usually multiple bit values) | 标志（一般是有多位的数值） |
| fn | Function | 函数 |
| g_ | Global | 全局的 |
| h | Handle | 句柄 |
| i | Integer | 整数 |
| l | Long | 长整数 |
| lp | Long Pointer | 长指针 |
| m_ | Data Member of a Class | 一个类的数据成员 |
| n | Short Integer | 短整数 |
| p | Pointer | 指针 |
| s | String | 字符串 |
| sz | Zero Terminated String | 以零结尾的字符串 |
| tm | Text Metric | 文本规则 |
| u | Unsigned Integer | 无符号整数 |
| ul | Unsigned Long(ULONG) | 无符号长整数 |
| w | WORD(Unsigned Short) | 无符号短整数 |
| x,y | x, y Coordinates (Short) | 坐标值（短整数） |
| v | Void | 空 |
有关项目的全局变量用g_开始，类成员变量用m_，局部变量若函数较大则可考虑用l_用以显示说明其是局部变量。
| 前缀 | 类型 | 例子 |
| g_ | 全局变量 | g_Servers |
| C | 类或者结构体 | CDocument, CPrintInfo |
| m_ | 成员变量 | m_pDoc, m_nCustomers |
VC常用前缀列表：
| 前缀 | 类型 | 描述 | 例子 |
| ch | char | 8位字符 | chGrade |
| ch | TCHAR | 16位Unicode集字符 | chName |
| b | BOOL | 布尔变量 | bEnable |
| n | int | 整型 | nLength |
| n | UINT | 无符整型 | nLength |
| w | WORD | 16位无符号整型 | wPos |
| l | Long | 32位有符号整型 | lOffset |
| dw | DWORD | 32位无符号整型 | dwRange |
| p | * | 指针变量，内存模块指针（Ambient memory model point) | pDoc |
| lp | Far* | 长指针 | lpDoc |
| lpsz | LPSTR | 32位字符串指针 | lpszName |
| lpsz | LPCSTR | 32位常量字符串指针 | lpszName |
| lpsz | LPCTSTR | 32位Unicode集常量指针 | lpszName |
| h | handle | Windows对象句柄 | hWnd |
| lpfn | (*fn)() | 回调函数指针 Callback Far pointer to CALLBACK function | lpfnAbort |
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 |
MSDN中给出了一段遵守代码风格和匈牙利命名法的代码参考如下：
1 #include "sy.h" 2 extern int *rgwDic; 3 extern int bsyMac; 4 struct SY *PsySz(char sz[]) 5 { 6 char *pch; 7 int cch; 8 struct SY *psy, *PsyCreate(); 9 int *pbsy; 10 int cwSz; 11 unsigned wHash=0; 12 pch=sz; 13 while (*pch!=0) 14 wHash=wHash<>11+*pch++; 15 cch=pch-sz; 16 pbsy=&rgbsyHash[(wHash&077777)%cwHash]; 17 for (; *pbsy!=0; pbsy = &psy->bsyNext) 18 { 19 char *szSy; 20 szSy= (psy=(struct SY*)&rgwDic[*pbsy])->sz; 21 pch=sz; 22 while (*pch==*szSy++) 23 { 24 if (*pch++==0) 25 return (psy); 26 } 27 } 28 cwSz=0; 29 if (cch>=2) 30 cwSz=cch-2/sizeof(int)+1; 31 *pbsy=(int *)(psy=PsyCreate(cwSY+cwSz))-rgwDic; 32 Zero((int *)psy,cwSY); 33 bltbyte(sz, psy->sz, cch+1); 34 return(psy); 35 }
=================================================
匈牙利命名法
中文名
匈牙利命名法
基本原则
变量名=属性+类型+对象描述
命 名
容易记忆容易理解的原则
原 则
保证名字的连贯性
目录
1简介编辑
例子
举例来说，表单的名称为form，那么在
匈牙利命名法中可以简写为frm，则当表单
变量名称为Switchboard时，变量全称应该为 frmSwitchboard。这样可以很容易从
变量名看出Switchboard是一个表单，同样，如果此变量类型为标签，那么就应命名成 lblSwitchboard。可以看出，
匈牙利命名法非常便于
记忆，而且使
变量名非常清晰易懂，这样，增强了
代码的可读性，方便各程序员之间相互交流代码。
Charles Simonyi
历史
据说这种命名法是一位叫 Charles Simonyi 的
匈牙利程序员发明的，后来他在
微软呆了几年，于是这种命名法就通过
微软的各种产品和文档资料向世界传播开了。大部分
程序员不管自己使用什么
软件进行开发，或多或少都使用了这种命名法。这种命名法的出发点是把
变量名按：属性+类型+对象描述的顺序组合起来，以使程序员作变量时对变量的类型和其它属性有直观的了解，下面是HN变量命名规范。
2变量属性编辑
属性部分：
g_
全局变量
c_
常量
m_ c++类
成员变量
s_
静态变量
类型部分：
数组 a
指针 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举例编辑
上面就是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
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反对声音编辑
匈牙利命名法是一种编程时的命名规范。命名规范是程序书写规范中最重要也是最富争议的地方，自古乃
兵家必争之地。命名规范有何用？四个字：名正言顺。用二分法，命名规范分为好的命名规范和坏的命名规范，也就是说名正言顺的命名规范和
名不正言不顺的命名规范。好的舞鞋是让舞者感觉不到其存在的舞鞋，坏的舞鞋是让舞者带着镣铐起舞。一个坏的命名规范具有的破坏力比一个好的命名规范具有的创造力要大得多。
成本
匈法的表现形式为给
变量名附加上
类型名前缀，例如：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 加上类型修饰，更是难上加难。
匈牙利命名法有其优点但也有缺点，这就需要在使用中扬长避短，合理应用它。
在LPCTSTR lpszClassName,LPCTSTR lpszWindowName，都用sz部分
lpsz表示long pointer string zero
匈牙利记法
sz为null结尾的字符串变量的前缀 以零结尾的字符串
s表示string
z表示zero
就是以NULL结尾的string
p=poiter
l=? //（long）
在注册表中，REG_SZ，是一种字符串类型，代表一个简单的文本字符串，是最常见的一种数据类型。
其中“SZ”是“String Zero”的缩写，匈牙利命名法，表示null结尾的字符串变量。
注：REG_SZ型注册表值项的名称是长度固定的文本字符串，最大长度不能超过255个字符，它的数据不限长度。通过Registry workshop可以将字符串值的名称更改为大于255个字符的长度，但该值将在RegEdit中不可见。[1]
1719
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
