匈牙利命名法则

时间: 2023-07-11 admin IT培训

匈牙利命名法则

匈牙利命名法则

几年以前,Charles Simonyi(他后来成为微软的著名程序员)设计了一种以前缀为基础的命名方法,这种方法后来称为"匈牙利表示法"以记念他.他的思想是根据每个标识符所代表的含义给它一个前缀.微软后来采用了这个思想,给每个标识符一个前缀以说明它的数据类型.因此,整型变量的前缀是n,长整型变量是nl,字符型数组变量是ca,以及字符串(以空类型结尾的字符数组)以sz为前缀.这些名字可能会非常古怪.比如说:lpszFoo表示"Foo"是一个指向以空字符为结尾的字符串的长整型指针.

 

这种方法的优点是使人能够通过变量的名字来辨别变量的类型,而不比去查找它的定义.遗憾的是,这种方法不仅使变量名字非常绕口,而且使改变变量类型的工作变得十分艰巨.在Windows3.1中,整型变量为16为宽.如果我们在开始时采用了一个整型变量,但是在通过30---40个函数的计算之后,发现采用整型变量宽度不够,这时我们不仅要改变这个变量的类型,而且要改变这个变量在这30--40个函数中的名字.

 

因为不切实际,除了一些顽固的Windows程序员外已经没有人再使用"匈牙利表示法"了.毫无疑问,在某种场合它依然存在,但大部分人现在已经抛弃它了.一般而言,输入前缀是一种糟糕的想法,因为它把变量于其类型紧紧地绑在了一起.


对于30行以下的函数,匈牙利方法一般有优势。

尤其是对界面编程,有优势。

但对于有强烈的算法要求、尤其是有很多抽象类型的C++程序,匈牙利方法简直是一个灾难。

看你用在什么地方。

现在有了很好的IDE工具,如:VC,SourceInsight等.

选中变量,会自动提示告诉你它的声明和定义,这样

匈牙利命名法就没有很大的必要了.

无非就是为了程序可读性较好.

实际上良好的代码书写习惯比强制使用匈牙利命名法更重要.


系统性。整体性。可读性。分类要清楚。要有注释!

 

匈牙利命名法是微软推广的一种关于变量、函数、对象、前缀、宏定义等各种类型的符号的命名规范。匈牙利命名法的主要思想是:在变量和函数名中加入前缀以增进人们对程序的理解。它是由微软内部的一个匈牙利人发起使用的,结果它在微软内部逐渐流行起来,并且推广给了全世界的Windows开发人员。下面将介绍匈牙利命名法,后面的例子里也会尽量遵守它和上面的代码风格。还是那句话,并不是要求所有的读者都要去遵守,但是希望读者作为一个现代的软件开发人员都去遵守它。

前缀类型中文说明
aArray数组
bBOOL(int)布尔(整数)
byUnsigned Char(Byte)无符号字符(字节)
cChar字符(字节)
cbCount of Bytes字节数
crColor Reference Value颜色(参考)值
cxCount of x(Short)x的集合(短整数)
fFlags(usually multiple bit values)标志(一般是有多位的数值)
fnFunction函数
g_Global全局的
hHandle句柄
iInteger整数
lLong长整数
lpLong Pointer长指针
m_Data Member of a Class一个类的数据成员
nShort Integer短整数
pPointer指针
sString字符串
szZero Terminated String以零结尾的字符串
tmText Metric文本规则
uUnsigned Integer无符号整数
ulUnsigned Long(ULONG)无符号长整数
wWORD(Unsigned Short)无符号短整数
x,yx, y Coordinates (Short)坐标值(短整数)
vVoid

有关项目的全局变量用g_开始,类成员变量用m_,局部变量若函数较大则可考虑用l_用以显示说明其是局部变量。

前缀类型例子
g_全局变量g_Servers
C类或者结构体CDocument, CPrintInfo
m_成员变量m_pDoc, m_nCustomers

VC常用前缀列表:

前缀类型描述例子
chchar8位字符chGrade
chTCHAR16位Unicode集字符chName
bBOOL布尔变量bEnable
nint整型nLength
nUINT无符整型nLength
wWORD16位无符号整型wPos
lLong32位有符号整型lOffset
dwDWORD32位无符号整型dwRange
p*指针变量,内存模块指针(Ambient memory model point)pDoc
lpFar*长指针lpDoc
lpszLPSTR32位字符串指针lpszName
lpszLPCSTR32位常量字符串指针lpszName
lpszLPCTSTR32位Unicode集常量指针lpszName
hhandleWindows对象句柄hWnd
lpfn(*fn)() 回调函数指针 Callback Far pointer to CALLBACK functionlpfnAbort

MFC、句柄、控件及结构的命名规范:

Windows类型样本变量MFC类样本变量
HWNDhWndCWnd*pWnd
HDLGhDlgCDialog*pDlg
HDChDCCDC*pDC
HGDIOBJhGdiObjCGdiObject*pGdiObj
HPENhPenCPen*pPen
HBRUSHhBrushCBrush*pBrush
HFONThFontCFont*pFont
HBITMAPhBitmapCBitmap*pBitmap
HPALETTEhPaltteCPalette*pPalette
HRGNhRgnCRgn*pRgn
HMENUhMenuCMenu*pMenu
HWNDhCtlCState*pState
HWNDhCtlCButton*pButton
HWNDhCtlCEdit*pEdit
HWNDhCtlCListBox*pListBox
HWNDhCtlCComboBox*pComboBox
HWNDhCtlCScrollBar*pScrollBar
HSZhszStrCStringpStr
POINTptCPointpt
SIZEsizeCSizesize
RECTrectCRectrect

一般前缀命名规范:

前缀类型实例
C类或结构Cdocument, CPrintInfo
m_成员变量m_pDoc, m_nCustomers

变量命名规范:

前缀类型描述实例
chchar8位字符chGrade
chTCHAR如果_UNICODE定义,则为16位字符chName
bBOOL布尔值bEnable
nint整型(其大小依赖于操作系统)nLength
nUINT无符号值(其大小依赖于操作系统)nHeight
wWORD16位无符号值wPos
lLONG32位有符号整型lOffset
dwDWORD32位无符号整型dwRange
p*指针pDoc
lpFAR*远指针lpszName
lpszLPSTR32位字符串指针lpszName
lpszLPCSTR32位常量字符串指针lpszName
lpszLPCTSTR如果_UNICODE定义,则为32位常量字符串指针lpszName
hhandleWindows对象句柄hWnd
lpfncallback指向CALLBACK函数的远指针 
前缀符号类型实例范围
IDR_不同类型的多个资源共享标识IDR_MAIINFRAME1~0x6FFF
IDD_对话框资源IDD_SPELL_CHECK1~0x6FFF
HIDD_对话框资源的Help上下文HIDD_SPELL_CHECK0x20001~0x26FF
IDB_位图资源IDB_COMPANY_LOGO1~0x6FFF
IDC_光标资源IDC_PENCIL1~0x6FFF
IDI_图标资源IDI_NOTEPAD1~0x6FFF
ID_来自菜单项或工具栏的命令ID_TOOLS_SPELLING0x8000~0xDFFF
HID_命令Help上下文HID_TOOLS_SPELLING0x18000~0x1DFFF
IDP_消息框提示IDP_INVALID_PARTNO8~0xDEEF
HIDP_消息框Help上下文HIDP_INVALID_PARTNO0x30008~0x3DEFF
IDS_串资源IDS_COPYRIGHT1~0x7EEF
IDC_对话框内的控件IDC_RECALC8~0xDEEF

应用程序符号命名规范

Microsoft MFC宏命名规范:

名称类型
_AFXDLL唯一的动态连接库(Dynamic Link Library,DLL)版本
_ALPHA仅编译DEC Alpha处理器
_DEBUG包括诊断的调试版本
_MBCS编译多字节字符集
_UNICODE在一个应用程序中打开Unicode
AFXAPIMFC提供的函数
CALLBACK通过指针回调的函数

库标识符命名法:

标识符值和含义
uANSI(N)或Unicode(U)
d调试或发行:D = 调试,忽略标识符为发行。

静态库版本命名规范:

描述
NAFXCWD.LIB调试版本:MFC静态连接库
NAFXCW.LIB发行版本:MFC静态连接库
UAFXCWD.LIB调试版本:具有Unicode支持的MFC静态连接库
UAFXCW.LIB发行版本:具有Unicode支持的MFC静态连接库

动态连接库命名规范:

名称类型
_AFXDLL唯一的动态连接库(DLL)版本
WINAPIWindows所提供的函数

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简介

▪ 例子
▪ 历史

2变量属性

3举例

4总结

5反对声音

▪ 成本
▪ 收益
▪ 实施

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举例编辑

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 加上类型修饰,更是难上加难。 匈牙利命名法有其优点但也有缺点,这就需要在使用中扬长避短,合理应用它。 =========================
在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]