幽幽
 
posts - 51,  comments - 28,  trackbacks - 0
抨击匈牙利命名法

匈牙利命名法是一种编程时的命名规范。命名规范是程序书写规范中最重要也是最富争议的地方,自古乃兵家必争之地。命名规范有何用?四个字:名正言顺。用二分法,命名规范分为好的命名规范和坏的命名规范,也就是说名正言顺的命名规范和名不正言不顺的命名规范。好的舞鞋是让舞者感觉不到其存在的舞鞋,坏的舞鞋是让舞者带着镣铐起舞。一个坏的命名规范具有的破坏力比一个好的命名规范具有的创造力要大得多。

本文要证明的是:匈牙利命名法是一个坏的命名规范。本文的作用范围为静态强类型编程语言。本文的分析范本为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 噩梦加上修饰是什么?还是噩梦。
posted on 2008-05-02 02:26 幽幽 阅读(2499) 评论(10)  编辑 收藏 引用 所属分类: 杂集

FeedBack:
# re: 抨击匈牙利命名法
2008-05-02 08:22 | lovedday
早就放弃匈牙利命名法了,匈牙利命名法可能在开发windows API的时候有用,那时的编译器的变量和函数提示功能没有那么强大,程序员可以从匈牙利命名法中得到好处。可是现在编译器的信息提示功能已经非常强大,匈牙利命名法实际上是一种累赘,带来的弊端远远超过它的好处,不利于代码阅读。  回复  更多评论
  
# re: 抨击匈牙利命名法
2009-08-11 11:22 | 合体星人
尽管楼主如此抨击匈牙利命名法,那为什么不提出一个更有效的命名系统?  回复  更多评论
  
# re: 抨击匈牙利命名法
2009-08-31 11:14 | 12311
是这样的,团队开发时必须有一个命名规范,而自己制定一整套规范的话既麻烦又产生大量学习成本,新成员加入后首先要让他适应新的规范,按照经验看,改变一个程序员的命名规范是很花时间的,所以往往都是采用大家认知度较高的一种既存规范,所以首选仍然是匈牙利。
另:没有大型团队合作项目经验的人没有资格对规范的东西提出抨击~~~  回复  更多评论
  
# re: 抨击匈牙利命名法
2009-11-09 19:30 | 晓宇
我很是期待看到你用100个i做变量的表情.
希望我不会碰到你写的程序

但是说实话,你很厉害,写这么多.而且还找了例子,从这点来说 确实很厉害.  回复  更多评论
  
# re: 抨击匈牙利命名法
2010-03-09 16:29 | koangel
如果你们去维护过其他人的代码,或参与过较大型产品的开发,就绝对不会这么说了,对于你们这种只会自己编码的人,怎么可能理解的到其中的内涵?井底之蛙  回复  更多评论
  
# re: 抨击匈牙利命名法
2010-04-23 13:04 | cvb
@合体星人
java程序员没有听说过所谓的命名法,但java程序的可读性仍然是最强的。
匈牙利命名法对VC程序有毁灭性的打击  回复  更多评论
  
# re: 抨击匈牙利命名法
2010-06-05 00:45 | 不想多说你了
无知~~  回复  更多评论
  
# re: 抨击匈牙利命名法
2010-08-10 20:36 | #
对你无话可说,只能说你无知  回复  更多评论
  
# re: 抨击匈牙利命名法[未登录]
2012-04-10 13:42 | Alex
庆幸楼主不是我同事
更庆幸楼主不是我老大  回复  更多评论
  
# re: 抨击匈牙利命名法
2013-03-15 10:56 | Linuxer
Linus 本人說匈牙利命名法是brain damaged 很中肯!
  回复  更多评论
  

只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理



<2013年3月>
242526272812
3456789
10111213141516
17181920212223
24252627282930
31123456

常用链接

留言簿(5)

随笔分类(35)

随笔档案(51)

文章分类(3)

文章档案(3)

相册

我的链接

搜索

  •  

最新评论

阅读排行榜

评论排行榜