以文本方式查看主题 - 计算机科学论坛 (http://bbs.xml.org.cn/index.asp) -- 『 C/C++编程思想 』 (http://bbs.xml.org.cn/list.asp?boardid=61) ---- 关于匈牙利命名法[转帖] (http://bbs.xml.org.cn/dispbbs.asp?boardid=61&rootid=&id=25652) |
-- 作者:darkhero -- 发布时间:12/19/2005 6:46:00 PM -- 关于匈牙利命名法[转帖] 匈牙利命名法来源 MFC、句柄、控件及结构的命名规范 VB Prefix命名规范 在编程时,变量、函数的命名是一个极其重要的问题。好的命名方法使变量易于记忆且程序可读性大大提高。Microsoft采用匈牙利命名法来命名Windows API函数和变量。匈牙利命名法是由Microsoft的著名开发人员、Excel的主要设计者查尔斯·西蒙尼在他的博士论文中提出来的,由于西蒙尼的国籍是匈牙利,所以这种命名法叫匈牙利命名法。 匈牙利命名法为C标识符的命名定义了一种非常标准化的方式,这种命名方式是以两条规则为基础: 1.标识符的名字以一个或者多个小写字母开头,用这些字母来指定数据类型。 2.在标识符内,前缀以后就是一个或者多个第一个字母大写的单词,这些单词清楚地指出了源代码内那个对象的用途。比如,m_szStudentName表示一个学生名字的类成员变量,数据类型是字符串型。 附录: MFC、句柄、控件及结构的命名规范 Windows类型 一般前缀命名规范 前缀 变量命名规范 前缀 抨击匈牙利命名法 匈牙利命名法是一种编程时的命名规范。命名规范是程序书写规范中最重要也是最富争议的地方,自古乃兵家必争之地。命名规范有何用?四个字:名正言顺。用二分法,命名规范分为好的命名规范和坏的命名规范,也就是说名正言顺的命名规范和名不正言不顺的命名规范。好的舞鞋是让舞者感觉不到其存在的舞鞋,坏的舞鞋是让舞者带着镣铐起舞。一个坏的命名规范具有的破坏力比一个好的命名规范具有的创造力要大得多。 本文要证明的是:匈牙利命名法是一个坏的命名规范。本文的作用范围为静态强类型编程语言。本文的分析范本为C语言和C++语言。下文中的匈法为匈牙利命名法的简称。 一 匈牙利命名法的成本 匈法的表现形式为给变量名附加上类型名前缀,例如:nFoo,szFoo,pFoo,cpFoo分别表示整型变量,字符串型变量,指针型变量和常指针型变量。可以看出,匈法将变量的类型信息从单一地点(声明变量处)复制到了多个地点(使用变量处),这是冗余法。冗余法的成本之一是要维护副本的一致性。这个成本在编写和维护代码的过程中需要改变变量的类型时付出。冗余法的成本之二是占用了额外的空间。一个优秀的书写者会自觉地遵从一个法则:代码最小组织单位的长度以30个自然行以下为宜,如果超过50行就应该重新组织。一个变量的书写空间会给这一法则添加不必要的难度。 二 匈牙利命名法的收益 这里要证明匈牙利命名法的收益是含糊的,无法预期的。 范本1:strcpy(pstrFoo,pcstrFoo2) Vs strcpy(foo,foo2) 范本2:unknown_function(nFoo) Vs unknown_function(foo) 范本3:nFoo=nBar Vs foo=bar 三 匈牙利命名法的实施 这里要证明匈牙利命名法在C语言是难以实施的,在C++语言中是无法实施的。从逻辑上讲,对匈法的收益做出否定的结论以后,再来论证匈法的可行性,是画蛇添足。不过有鉴于小马哥曾让已射杀之敌死灰复燃,我还是再踏上一支脚为妙。 前面讲过,匈法是类型系统的冗余,所以实施匈法的关键是我们是否能够精确地对类型系统进行复制。这取决于类型系统的复杂性。 先来看看C语言: 1.内置类型:int,char,float,double 复制为 n,ch,f,d?好像没有什么问题。不过谁来告诉我void应该怎么表示? 噩梦还没有结束,再来看看类型系统更阿为丰富的C++语言: 1.class:如果说C语言中的struct还可以用stru搪塞过去的话,不要梦想用cls来搪塞C++中的class。严格地讲,class根本就并不是一个类型,而是创造类型的工具,在C++中,语言内置类型的数量和class创造的用户自定义类型的数量相比完全可以忽略不计。stdvectorFoo表示标准库向量类型变量Foo?疯狂的念头。 你愿意做镣铐上的舞者吗? |
-- 作者:vdgame -- 发布时间:1/25/2006 8:36:00 AM -- 感觉很难实施! |
W 3 C h i n a ( since 2003 ) 旗 下 站 点 苏ICP备05006046号《全国人大常委会关于维护互联网安全的决定》《计算机信息网络国际联网安全保护管理办法》 |
46.875ms |