匈牙利命名法
匈牙利命名法是一种编程时的命名规范。基本原则是:变量名=属性+类型+对象描述,其中每一对象的名称都要求有明确含义,可以取对象名字全称或名字的一部分。命名要基于容易记忆容易理解的原则。保证名字的连贯性是非常重要的。
举例来说,表单的名称为form,那么在匈牙利命名法中可以简写为frm,则当表单变量名称为
Switchboard时,变量全称应该为
frmSwitchboard。这样可以很容易从变量名看出Switchboard是一个表单,同样,如果此变量类型为标签,那么就应命名成
lblSwitchboard。可以看出,匈牙利命名法非常便于记忆,而且使变量名非常清晰易懂,这样,增强了代码的可读性,方便各程序员之间相互交流代
码。
据说这种命名法是一位叫 Charles Simonyi
的匈牙利程序员发明的,后来他在微软呆了几年,于是这种命名法就通过微软的各种产品和文档资料向世界传播开了。现在,大部分程序员不管自己使用什么软件进
行开发,或多或少都使用了这种命名法。这种命名法的出发点是把变量名按:属性+类型+对象描述的顺序组合起来,以使程序员作变量时对变量的类型和其它属性
有直观的了解,下面是HN变量命名规范,其中也有一些是我个人的偏向:
属性部分
全局变量
g_
常量
c_
c++类成员变量
m_
静态变量
s_
类型部分
指针
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
这里顺便写几个例子:
hwnd : h 是类型描述,表示句柄, wnd 是变量对象描述,表示窗口,所以 hwnd 表示窗口句柄;
pfnEatApple : pfn 是类型描述,表示指向函数的指针, EatApple 是变量对象描述,所以它表示
指向 EatApple 函数的函数指针变量。
g_cch : g_ 是属性描述,表示全局变量,c 和 ch 分别是计数类型和字符类型,一起表示变量类
型,这里忽略了对象描述,所以它表示一个对字符进行计数的全局变量。
上面就是HN命名法的一般规则。
小结:匈牙利命名法
匈牙利命名法
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
--------------------------------------------------------------------------------
抨击匈牙利命名法
匈牙利命名法是一种编程时的命名规范。命名规范是程序书写规范中最重要也是最富争议的地方,自
古乃兵家必争之地。命名规范有何用?四个字:名正言顺。用二分法,命名规范分为好的命名规范和坏的命名规范,也就是说名正言顺的命名规范和名不正言不顺的
命名规范。好的舞鞋是让舞者感觉不到其存在的舞鞋,坏的舞鞋是让舞者带着镣铐起舞。一个坏的命名规范具有的破坏力比一个好的命名规范具有的创造力要大得
多。
本文要证明的是:匈牙利命名法是一个坏的命名规范。本文的作用范围为静态强类型编程语言。本文的分析范本为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://blog.163.com/ccbobo_cat/blog/static/32099462200931411226261
分享到:
相关推荐
公共和受保护的成员不使用匈牙利命名法。 7. **预定义类型**:优先使用C#预定义的类型(如`object`、`string`和`int`),而不是System命名空间中的别名(如`Object`、`String`和`Int32`)。 8. **泛型**:在泛型中...
- **命名规则**:遵循特定的命名约定,例如使用拼音首字母命名数据项,采用匈牙利命名法命名变量。 - **开发模式**:采用敏捷开发方法。 #### 二、项目工作内容与参与人员 **2.1 工作内容** - **阶段性目标**:...
8. **NamingConventions**:检查变量、类、方法等的命名是否符合约定,如使用匈牙利命名法或驼峰命名法。 9. **SizeViolations**:限制代码的长度,比如单个类的大小、方法的行数等,以保持代码的简洁性。 10. **...
- 公共和受保护的成员不使用匈牙利命名法。 - 不要缩写变量名,如使用`number`而非`num`。 - 使用描述性的变量名,提高代码可读性。 3. **类型和命名空间**: - 使用C#预定义类型,如`int`而非`Int32`,`string...
同时,C#不鼓励使用匈牙利命名法,这是一种早期流行的命名约定,其中标识符包含了类型信息,但现在已被认为过时且冗余。 #### 关键字概览 C#中有76个关键字,它们在语言中具有固定的含义,不可用作变量或类名,...
变量命名遵循匈牙利标记法,对于每一个变量,都需在基础名中含有有意义的简短的描述。基础命名的每个单词的首字母必须大写,其他字母小写。例如:FileSize。 变量命名规则: * 数据类型 + BOOL:x + BYTE:by +...
- 遵循Sun/Oracle的Java编程规范,例如使用`驼峰命名法`,避免`匈牙利记法`。 - 避免使用过时的API和特性,保持代码的现代性。 9. **测试** - 编写单元测试,确保代码功能的正确性。 - 使用自动化测试框架如...
2. **命名规则**(第3章):遵循一致的命名规范,如匈牙利命名法或驼峰命名法,有助于识别变量、函数和类的类型和用途。变量名应具有描述性,避免使用单字母名称,除非在局部范围内非常明确。 3. **内存管理**(第7...
- 避免使用匈牙利命名法,除非在特定情况下,如表示类型的变量。 ### 2. 代码结构 - 使用空行和空格来增加代码的可读性。方法内逻辑相关的代码块之间保持适当间距。 - 遵循单一职责原则(SRP),确保每个类和方法...
匈牙利命名法是常见的编程命名规范,它要求变量名应该体现出变量的属性、类型以及对象描述,以助于程序员更好地理解和记忆。在PLC标签编程中,采用类似的命名规则,可以提高代码的可读性,并便于程序员间的交流。...
- **匈牙利命名法**:虽然在早期开发中流行,但在现代C#编程实践中并不推荐使用。 #### 三、关键字 C#具有丰富的关键字集合,这些关键字用于定义程序的基本结构和行为。例如: - **`abstract`**: 表示类或成员...
- 不推荐使用匈牙利命名法,例如在`GrammarHelper`类中,`Optional`方法和`optional`变量的命名。 3. **关键字**: C#语言拥有76个关键字,包括`abstract`, `as`, `base`, `bool`, `break`, `byte`, `case`, `...
尽量避免使用缩写,并且不推荐使用匈牙利命名法,这种命名方式在变量名中包含了数据类型的信息,虽然在某些情况下有助于代码阅读,但在C#中并不常见。 C#拥有一套完整的关键词集,共有76个关键字,包括`abstract`、...
遵循一定的命名规则,如匈牙利命名法和驼峰命名法,可以使代码更具可读性。 **C#预处理器指令** 预处理器指令如#define、#undef、#if等,用于在编译期间处理代码,实现条件编译和定义常量等功能。 总之,这个C#...
避免使用缩写和匈牙利命名法,保持代码的清晰易读。 C#的关键字是语言预定义的特殊标识符,具有特定含义。教程提到了几个关键字,如`abstract`、`as`、`base`、`bool`等,它们在不同的上下文中扮演着特定的角色。...
- **说明**:虽然文档中提到不推荐使用匈牙利命名法(如 `m_sName`),但在实际开发中,使用特定的前缀来区分变量类型和作用域仍然是常见的做法。 以上内容总结了 ASP.NET 和 C# 开发过程中的一些基础知识和技术...