匈牙利命名法是一种编程时的命名规范。基本原则是：变量名＝属性＋类型＋对象描述，其中每一对象的名称都要求有明确含义，可以取对象名字全称或名字的一部分。命名要基于容易记忆容易理解的原则。保证名字的连贯性是非常重要的。 举例来说，表单的名称为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 描述部分 {zd0} 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 {wy}的动态连接库（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 {wy}的动态连接库（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) 匈法在这里有什么收益呢？我看不到。对于一个不知道确定类型的函数，程序员应该去查看该函数的文档，这是一种成本。使用匈法的{wy}好处是看代码的人知道这个函数要求一个整型参数，这又有什么用处呢？函数是一种接口，参数的类型仅仅是接口中的一小部分。诸如函数的功能、出口信息、线程安全性、异常安全性、参数合法性等重要信息还是必须查阅文档。 范本3：nFoo=nBar Vs foo=bar 匈法在这里有什么收益呢？我看不到。使用匈法的{wy}好处是看代码的人知道这里发生了一个整型变量的复制动作，听起来没什么问题，可以安心睡大觉了。如果他看到的是nFoo=szBar，可能会从美梦中惊醒。且慢，事情真的会是这样吗？我想首先被惊醒的应该是编译器。另一方面，nFoo=nBar只是在语法上合法而已，看代码的人真正关心的是语义的合法性，匈法对此毫无帮助。另一方面，一个优秀的书写者会自觉地遵从一个法则：代码最小组织单位中的临时变量以一两个为宜，如果超过三个就应该重新组织。结合前述{dy}个法则，可以得出这样的结论：易于理解的代码本身就应该是易于理解的，这是代码的内建高质量。好的命名规范对内建高质量的助益相当有限，而坏的命名规范对内建高质量的损害比人们想象的要大。 三 匈牙利命名法的实施 这里要证明匈牙利命名法在C语言是难以实施的，在C++语言中是无法实施的。从逻辑上讲，对匈法的收益做出否定的结论以后，再来论证匈法的可行性，是画蛇添足。不过有鉴于小马哥曾让已射杀之敌死灰复燃，我还是再踏上一支脚为妙。 前面讲过，匈法是类型系统的冗余，所以实施匈法的关键是我们是否能够xx地对类型系统进行复制。这取决于类型系统的复杂性。 先来看看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创造的用户自定义类型的数量相比xx可以忽略不计。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 噩梦加上修饰是什么？还是噩梦。 匈牙利表示法 匈牙利表示法概述 密码- -间谍电影和其它各种人类活动的基本素材。当你{dy}次看到匈牙利表示法时，你可能会把它当成另一种密码。该表示法包含了密码的一切要素，其中包括一系列不得不解码的神秘字符以及使用时几乎不能破译的结果。然而，不久你就会明白，这是其他程序员的秘密代码，而不是本书中使用的匈牙利表示法。 匈牙利表示法可以为你节省大量的时间和精力。在编程方面花过大量时间的任何人都知道，当阅读以前自己编写的代码或阅读其他人编写的代码时，好的文档是无价之宝。这也正是匈牙利表示法要为你完成的任务- -文档化代码。 对匈牙利表示法的清晰理解将有助于你从本书的示例以及Microsoft （以及其他厂商）的手册中学到更多深入的东西。每一个Windows 编程语言厂商都在其手册中使用某种形式的匈牙利表示法。另外，相同的概念同样适用于诸如Visual FoxPro ，Delphi 以及Visual Basic这样的编程语言。即使语言本身xx不同，但使用匈牙利表示法编写出的代码超越了编程语言而具备一定的相似性。 那么，严格讲起来，什么是匈牙利表示法呢？匈牙利表示法是一种告诉其他人你准备如何使用变量的表示方法。知道了变量要干些什么经常有助于解释代码本身。例如，如果我告诉你某个特定变量保存了某个窗口的句柄，那么这就比变量只简单地是个变量提供了更多的信息。理解了该变量将操作窗口后，你就可以解释代码了。 这种变量命名系统{dy}阶段的开发工作是由Microsoft 公司的Charles Simonyi 完成的。他把这种命名系统称做匈牙利表示法（Hungarian Notation ），我们在这里就使用这种称呼。你可以从许多地方获取Charles Simonyi 著作的副本，包括BBS 和Internet 上的某些icrosoft编程站点（像CompuServer 这样的许多联机服务也以各种形式提供匈牙利表示法的副本）。 其他开发人员对Simonyi 的研究成果做了进一步的增强。例如，Xbase 程序员使用他们自己特殊版本的匈牙利表示法。这种表示法表达了Xbase 提供的不同类型的变量。FreshTechnologies 的Robert A. Difalco 出版了匈牙利表示法的Xbase 增强版本。在某些针对DBMS的BBS 上以及CompuServer 的Computer Associates Clipper 论坛上你都可以找到这位作者的作品。 本节讲述的基本概念在前面提到的两个文档中你都可以查阅到，表达形式上可能会有所不同。本节旧话重提的目的是为了让你准确地理解我所采用的约定的意义，并说明在你的代码中应该如何{zj0}地使用它们。在你的代码中采用这种命名法的原因有四个： 帮助记忆值 这种表示法有助于更容易地记住变量的名称，在团队项目中这是个要认真考虑的重要事情。 提供建议值 你或许并不是{wy}要修改你的代码的人。如果你正在开发一个团队项目的话，小组中的其他成员最起码也要看一看你编写的代码。使用这些约定有助于其他开发人员理解你的代码。 一致性 程序员的工作成果通常并不仅仅体现在效率和功能方面，而且也体现在编写出的代码是否能够被其他程序员轻易地读懂。使用这些约定有助于在不同的项目中保持一致的代码风格。利用你所使用的约定，其他程序员也可以轻易地加入到修改或编写代码的行列中。 加快判断速度 在商业化世界中，创建和修改代码的速度经常会决定特定项目的成功程度。使用一致的代码将减少你花在猜测其他人创建的变量或函数意义方面所需的时间。这一判断时间的减少也就增加了你用于有效地开发产品的时间。 上面已经讲述了为什么应该使用匈牙利表示法，现在让我们看一看本书中准备如何应用这一表示法吧。我将按照下节阐述的规则命名变量。在命名数据库字段或其它与值相关的结构时我也将使用这些规则。另外，只要匈牙利表示法有助于更清晰地表达函数和过程的意义，这些函数和过程的命名也将使用下节中介绍的规则。 规则1：使用变量前缀 变量命名时，总使用一个或两个小写字母作为变量名前缀，以指明变量的类型。绝大多数情况下，变量名前缀使用变量类型的{dy}个字母，因此，可以轻易地记住应该使用哪个字母。下面的示例显示了Visual Basic ，Delphi 以及C 语言中普遍使用的前缀字母（Windows.中有成千上万种文字组合没有在这里列出）。 下表也提供了几个数据库专用的修饰符： A Array C Character D Date Dbl Double Dc Device Context Dw Double Word F Flag,Boolean或Logical H Handle I Integer Inst Instance L Long Li Long Integer Lp Long Point Msg Message N Numeric O Object Pal Palette Psz 指向以零结尾的字符串的指针（Pointer） Ptr 指针（与其它类型变量一起使用时也可以使用p，比如psz） R Real.续表 Rc Rectangle Rgb Red,Green,Blue（红、绿、蓝，颜色变量） Rsrc Resource Sgl Single Si Short Integer Sz Zero Terminated String U Unsigned Ui Unsigned Integer或Byte W Word Wnd Window 规则2：标识状态变量 某些变量用于指明像数据库、字段或控件这样的对象的状态。这些变量甚至可以保存其它变量的状态。告诉其他程序员某个变量用于监视某个对象的当前状态有助于他们理解这些变量在程序中的意义。你可以使用下面的三字母修饰符之一来指明该变量是状态变量： New 新的状态 Sav 已保存状态 Tem 临时状态 规则3：应用标准修饰符 标准修饰符几乎可以让其他人立即看清楚变量的用途。标准修饰符不提供变量的类型信息，但它们说明了一个变量与其它变量之间的关系。例如，使用Clr 修饰符将会告诉阅读程序的人该变量以某种方式用于操作颜色。你甚至可以把多个修饰符组合起来以进一步说明变量的作用并描述清楚应该如何使用这个变量。例如，cClrCrs 是个字符型变量，它用于确定光标的显示颜色。使用一到三个这样的修饰符通常就足以描述清楚变量的用途了。 下面列出的修饰符是应用最普遍的一些修饰符： Ar Array Attr Attribute B Bottom Clr Color Col Column Crs Cursor Dbf Database File（数据库文件） F First File File Fld Field L Last/Left Msg Message Name Name Ntx Index File（索引文件） R right Rec Record Number（记录号）续表 Ret Return Value（返回值） Scr Screen Str String T Top X Row Y Column 规则4：添加描述性文字 当你清楚地定义了变量的内容和用途后，就可以使用一些描述性的文字进一步精化这些定义。例如，你可以把指向用于保存雇员姓名的字符串的长型指针变量定义为：lpszEmpName 。这个变量的前两个字母告诉我们它是个长型指针，紧接着的两个字母告诉我们这是个以零（或空）结尾的字符串，其余的字母告诉我们它是个雇员姓名（请注意，在这个示例中我使用了标准修饰符Name ）。在代码中看到这样的变量名让人一眼就可以看出其类型和用途。 规则5：创建多个变量 时不时就会遇到在某个特定模块中使用一个变量并不能够满足每一种需要的情况。多数情况下你会想到创建同种类型的多个变量，并用数字来区分这些变量。当然你也可以使用下面的这种有意义的数字指示符来说明各变量的功能：1 ，2 ，3 状态指针引用，比如SavClr1 ，cSavClr2 ，… Max 限制上界，比如nFldMax指明字段的{zd0}个数 Min 限制下界，比如nRecMin指明记录的最小个数 Ord 某种类型的顺序号
来自 |
郑重声明：资讯 【匈牙利命名法_我很懒...】由 发布，版权归原作者及其所在单位，其原创性以及文中陈述文字和内容未经(企业库qiyeku.com)证实，请读者仅作参考，并请自行核实相关内容。若本文有侵犯到您的版权， 请你提供相关证明及申请并与我们联系（qiyeku # qq.com）或【在线投诉】，我们审核后将会尽快处理。
—— 相关资讯 ——
