匈牙利命名法
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 |
以上转载来自:http://www.csdn.com.cn/program/5755.htm
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 空
以上转载来自:http://seanlee.blogbus.com/logs/2004/12/560998.html
抨击匈牙利命名法
匈牙利命名法是一种编程时的命名规范。命名规范是程序书写规范中最重要也是最富争议的地方,自古乃兵家必争之地。命名规范有何用?四个字:名正言顺。用二分法,命名规范分为好的命名规范和坏的命名规范,也就是说名正言顺的命名规范和名不正言不顺的命名规范。好的舞鞋是让舞者感觉不到其存在的舞鞋,坏的舞鞋是让舞者带着镣铐起舞。一个坏的命名规范具有的破坏力比一个好的命名规范具有的创造力要大得多。
本文要证明的是:匈牙利命名法是一个坏的命名规范。本文的作用范围为静态强类型编程语言。本文的分析范本为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 噩梦加上修饰是什么?还是噩梦。
你愿意做镣铐上的舞者吗?
抨击匈牙利命名法
匈牙利命名法是一种编程时的命名规范。命名规范是程序书写规范中最重要也是最富争议的地方,自古乃兵家必争之地。命名规范有何用?四个字:名正言顺。用二分法,命名规范分为好的命名规范和坏的命名规范,也就是说名正言顺的命名规范和名不正言不顺的命名规范。好的舞鞋是让舞者感觉不到其存在的舞鞋,坏的舞鞋是让舞者带着镣铐起舞。一个坏的命名规范具有的破坏力比一个好的命名规范具有的创造力要大得多。
本文要证明的是:匈牙利命名法是一个坏的命名规范。本文的作用范围为静态强类型编程语言。本文的分析范本为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 噩梦加上修饰是什么?还是噩梦。
你愿意做镣铐上的舞者吗?