虽然极度讨厌遵照匈牙利命名法写的代码，但是公司的编码规范的命名部分是遵照匈牙利
约定的，所以还是硬着头皮去客观的了解一下；
9.5.5 匈牙利约定优点
匈牙利约定与其它命名约定一样，拥有由命名约定所带来的一切共同优点。由于有这样
多的标准名称，因此在任何一个单个子程序或程序中要特殊记忆的名字是非常少的。匈牙利
约定完全可以在不同项目中采用。
匈牙利约定可以使得在命名中容易产生定义的区域变得准确清楚。特别是约定中对
First，Min，Last，Max 和 Lim 的准确区分在实际中是尤其有帮助的。匈牙利约定可以使
人对编译程序无法检查的抽象数据类型进行检查：cpaReformat[i]很可能是错误的，因为
cpaReformat 不是数组，而 apaReformat[i]则可能是正确的，因为 apaReformat[i]是数
组。
匈牙利约定可以在类型不严格的语言或环境中对类型进行说明。例如，在 Windows 环
境下编程时，需要你放弃许多类型，这极大地限制了编译程序进行严格类型检查的能力。
而建立约定则可以对环境的这一弱点作出补偿，匈牙利约定还可以使名称更简洁，可以用
CMedals 而不用 TotalMedals 来代表奖牌的数量，使用 pNewScore，而不是用
NewScorePtr 命名一个新分数指针。
9.5.6 匈牙利约定缺点
一些版本的匈牙利约定事实上忽视了用抽象数据类型作为基本类型。它们以程序语言
中整型、长整型、浮点数和字符串为基础来建立基本类型。匈牙利约定基本类型事实上是
没有什么价值的，因为它使得程序员陷入对类型进行人工检查的困扰之中，而不是让编译
程序对类型进行更加快速而又准确的检查。
这种形式匈牙利约定的另一个问题是它把数据的意义与其表现联系在一起。比如，说
明某一变量是整型的，把它改为长整型的时，不得不改动这一变量的名称。
匈牙利约定的最后一个问题是它鼓励了懒惰、不含什么信息的变量名的出现。当程序
员用hwnd 来命名对窗口的操作时，往往忽视了他所指的到底是哪种窗口、对话框、菜单还
是帮助区的屏幕？显然用 hwndmenu 要比 hwnd 清楚得多。以变量的意义为代价来获得对
其类型的精确描述显然是愚蠢的。不过好在可以用加限定词的办法来同时获得完整的意义
和精确的类型。
================================================================================
几年以前,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的集合(短整数)
dw DWORD (unsigned long) 双字(无符号长整数)
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 int 短整数
p Pointer 指针
s String 字符串
sz Zero terminated String 以0结尾的字符串
tm Text metric 文本规则
u Unsigned int 无符号整数
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 布尔变量 bEnabled
n int 整型（其大小由操作系统决定） nLength
n UINT 无符号整型（其大小由操作系统决定） nLength
w WORD 16位无符号整型 wPos
l LONG 32位有符号整型 lOffset
dw DWORD 32位无符号整型 dwRange
p * Ambient memory model pointer 内存模块指针，指针变量 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
Windows对象名称缩写：
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 hPalette; CPalette* pPalette;
HRGN hRgn; CRgn* pRgn;
HMENU hMenu; CMenu* pMenu;
HWND hCtl; CStatic* pStatic;
HWND hCtl; CButton* pBtn;
HWND hCtl; CEdit* pEdit;
HWND hCtl; CListBox* pListBox;
HWND hCtl; CComboBox* pComboBox;
VC常用宏定义命名列表：
前缀 符号类型 符号例子 范围
IDR_ 标识多个资源共享的类型 IDR_MAINFRAME 1~0x6FFF
IDD_ 对话框资源（Dialog） IDD_SPELL_CHECK 1~ 0x6FFF
HIDD_ 基于对话框的上下文帮助 HIDD_SPELL_CHECK 0x20001~0x26FF
IDB_ 位图资源（Bitmap） IDB_COMPANY_LOGO 1~0x6FFF
IDC_ 光标资源（Cursor） IDC_PENCIL 1~0x6FFF
IDI_ 图标资源（Icon） IDI_NOTEPAD 1~0x6FFF
ID_、IDM_ 工具栏或菜单栏的命令项 ID_TOOLS_SPELLING 0x8000~0xDFFF
HID_ 命令上下文帮助 HID_TOOLS_SPELLING 0x18000~0x1DFFF
IDP_ 消息框提示文字资源 IDP_INVALID_PARTNO 8~0xDFFF
HIDP_ 消息框上下文帮助 HIDP_INVALID_PARTNO 0x30008~0x3DFFF
IDS_ 字符串资源（String） IDS_COPYRIGHT 1~0x7FFF
IDC_ 对话框内的控制资源 IDC_RECALC 8~0xDFFF
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[])
6 {
7 char *pch;
8 int cch;
9 struct SY *psy, *PsyCreate();
10 int *pbsy;
11 int cwSz;
12 unsigned wHash=0;
13 pch=sz;
14 while (*pch!=0)
15 wHash=wHash<>11+*pch++;
16 cch=pch-sz;
17 pbsy=&rgbsyHash[(wHash&077777)%cwHash];
18 for (; *pbsy!=0; pbsy = &psy->bsyNext)
19 {
20 char *szSy;
21 szSy= (psy=(struct SY*)&rgwDic[*pbsy])->sz;
22 pch=sz;
23 while (*pch==*szSy++)
24 {
25 if (*pch++==0)
26 return (psy);
27 }
28 }
29 cwSz=0;
30 if (cch>=2)
31 cwSz=cch-2/sizeof(int)+1;
32 *pbsy=(int *)(psy=PsyCreate(cwSY+cwSz))-rgwDic;
33 Zero((int *)psy,cwSY);
34 bltbyte(sz, psy->sz, cch+1);
35 return(psy);
36 }
阅读(3335) | 评论(0) | 转发(0) |
