匈牙利命名法

 

匈牙利命名法


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

Windows类型样本变量MFC类样本变量
HWNDhWnd;CWnd*pWnd;
HDLGhDlg;CDialog*pDlg;
HDChDC;CDC*pDC;
HGDIOBJhGdiObj;CGdiObject*pGdiObj;
HPENhPen;CPen*pPen;
HBRUSHhBrush;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

变量命名规范

前缀类型描述实例
chchar8位字符chGrade
ch TCHAR如果_UNICODE定义,则为16位字符chName
bBOOL布尔值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_MAIINFRAME1~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 噩梦加上修饰是什么?还是噩梦。

你愿意做镣铐上的舞者吗?

以上转载来自:http://www.csdn.com.cn/program/7183.htm

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值