匈牙利命名法对程序员有百弊而无一利。

Question

初学MFC的人，好像都有种感觉，被长长的变量名称弄得昏头转向，但两年后回过头一看，不就是那100多个类吗？
QT类库比它大得多，但学QT如行云流水，感觉很清爽。java类库比MFC大何止百倍，也不感觉有多少障碍。
到底是什么造成了学MFC如此费力、蹩脚，经过反思比较，偶以为这个糟糕的匈牙利命名法起到了极为恶劣的破坏性作用。
1.  匈法给变量名附加上类型名前缀，例如：nFoo,szFoo,pFoo,cpFoo分别表示整型变量，字符串型变量，指针型变量和常指针型变量。可以看出，匈法将变量的类型信息从单一地点（声明变量处）复制到了多个地点（使用变量处），这是冗余法。冗余法的成本之一是要维护副本的一致性。这个成本在编写和维护代码的过程中需要改变变量的类型时付出。冗余法的成本之二是占用了额外的空间，影响了程序员的视觉，导致理解变量含义需要拐个弯。
例如 strcpy(pstrSource,pcstrDest) 
 程序员要从变量名称中剔除“pstr”之类的前缀找到Source、Dest才能理解变量含义。
相比 strcpy(source,dest) 到底哪个优越？不要说匈法能“提示变量类型、避免的程序员出错”的所谓优点，如果连参数类型都搞不清楚，还算什么程序员？有疑问直接查文档好了，再说如果你不知道参数含义的话，即使你知道参数类型，你敢随便用吗？还不是一样要查文档？变量的命名，首要就是简洁，含义明确，把多方面的类型信息掺杂进变量名称有百害而无一利。

Answer 1

匈牙利命名法把不到200个类的MFC基础类库，搞得比上万个类的java基本类库还看着繁琐、碍眼，这到底算一大贡献还是一大搅屎棍子。

Answer 2

MFC类库初看是挺庞大的，也许LZ说的不无道理。

Answer 3

回头看就那么不到200个类，但QT类库学起来就那么清爽呢？
不信大家可以试验一下，把QT类库用匈牙利命名法重新进行命名，马上QT就变得面目狰狞、让人望而生畏，好像一堆刺猬蹲在你面前。

Answer 4

的确是不够清爽,但是楼主你晓得Windows刚刚起步的时候,编辑器还不够智能,没有Eclipse,Vs,Borland系列中的智能提示.
在一大堆函数中凭借匈牙利命名法的确可以降低阅读代码的难度.这是历史遗留问题,以及向后兼容问题,传说中的高手崇拜问题等等.楼主,哈?

Answer 5

MFC类看着繁琐、碍眼，那是一些其他机制导致的，宏、消息映射等等，关变量啥事？
strcpy(pstrSource,pcstrDest)  如果这个你都看不懂，只能说你差
你觉得QT看着清爽，我觉得MFC看着清爽，只能说你平时看QT多一些，我平时看MFC多一些，何必厚此薄彼？照你这么说，变量定义也不用区分类型了，如果编译器连类型都识别不了，那还叫啥编译器，是不？

Answer 6

strcpy(pstrSource,pcstrDest)比strcpy(source,dest)清爽？

Answer 7

strcpy(pstrSource,pcstrDest)显然比strcpy(source,dest)的信息量要大，尤其在多个重载函数的情况下，这种信息至关重要，相信你也遇到过

Answer 8

也没有楼主说得那么夸张吧，MFC类库说实话也谈不上有多复杂啊，各人的习惯吧

Answer 9

呵呵，我的代码变量类型要么不写，要么写在后面。
比如
int yearint;
CString yearstr;

Answer 10

一般习惯都是
int year;
CString year;除非在一个块中需要区分一下。含义写在前面比写在后面强，至少人们看变量的时候，首先关注的是含义，含义明白了，类型也猜个八九不离十了。

Answer 11

strcpy(s,d) 更清爽？
sc(s,d) 超级清爽？

Answer 12

有谁严格 遵守 匈牙利了？ 有谁要求 严格遵守 匈牙利了？
   LZ 突然提个 匈牙利  是被 谁 要求了？？ 
     百弊无一利 这个词  你用的 也太 那个撒了？ 专业砸场子的？？MFC我觉得很清爽， 你站我面前，我能顺口给你念上 20~30个，没问题，顺手给你画个继承图 没问题。。
：） 

Answer 13

类似在 Java 中讨论 final 修饰。

Answer 14

你老糊涂了,看看Windows方面的经典著作,哪本不是用的匈牙利命名法,哪个作者不是高手,哪个高手烦他了,哪个高手跑到CSDN扔月经带了.

Answer 15

关于楼主说的要改变量类型的时候,要慢慢改变量的名称.现在有VA,不怕了,一下就可以改好了.VS2005的C#,没VA也可以一下改好.

Answer 16

现在新型语言的API文档没有用这个命名法的，说明这个命名法确实不受欢迎，很让人烦，给阅读API文档设置了障碍。

Answer 17

现在连C#里，也不怎么用这个命名法，看来这个命名法不是一般的烂。新兴语言的API文档没见到谁用这个命名法的，谁见到过？

Answer 18

膜拜一下，同时求一个继承图
[email protected]

Answer 19

c语言的数据类型之间有兼容性问题，编译器的警告提示也有差异，在代码行比较多的时候，使用匈牙利命名法可以为程序员提供很多有用的信息，控制一些极其细微的错漏
还是编程习惯问题，除了极其局部的几个严格统一的保留变量外(i,j,n,x,b,e...)，没有说明前缀的变量绝对禁止

Answer 20

你个白痴。干脆你变量名全 a b c d 得了，你懂个屁啊，发这种帖子。
有本事你整个命名法出来？

Answer 21

我是来顶一下15L的我还从来没因为变量名问题BS某个类库

Answer 22

楼主只见其表，未见其里。
C#是强类型语言，下面这样的语言是无法通过编译的。
int a = 1;
if ( a )
  Console.WriteLine("Hello World.");而c++不同，类似的代码在mfc代码中可以编译通过。
既然程序员可能并不清楚if后面的括号里面是什么样的值，也许最好的办法就是在变量前加前缀。
这样可以避免不同类型混用所带来的潜在错误。

Answer 23

我就随波逐流了，在不同平台上都随主流，照葫芦画瓢，尽量符合大部分人的书写和阅读习惯在Windows平台我用 nTheIntVariant，可能会加上 m_ g_ 前缀
跨平台和/或通用库我用 the_int_variant
脚本语言我用 theIntVariant任何命名法都可以接受，没觉得哪个好哪个不好。

Answer 24

俺使用 _ 多，经常 g____xxxxxxxx;

Answer 25

发现楼主的观点一般都比较新颖，匈牙利命名法的出现是有他的历史原因的，MFC采用了这种命名规范，说明他就是有存在价值的。你把他说的“百弊而无一利”，只能说明你无知了。
记得曾经在一个帖子里跟楼主争过数学在软件开发中的作用，你当时也是说，数学在软件开发中不但没有促进的作用，相反却是一种阻碍。真不知道你为什么会有这样的想法？

Answer 26

是windows系统API是这样的命名规则，MFC不过是对底层进行封装，很多参数和类型都是依照操作系统的，不是说改就该改的，也许会造成很多混乱，用久了习惯就好，刚开始不习惯是正常的

Answer 27

顶17楼！
楼主你错了，正确的写法应该是strcpy(pszSource, pszDest)！这才是正确的匈牙利写法！
我用了十多年MFC我觉得匈牙利表示法能够帮人快速了解参数信息，反倒是LZ的strcpy(source, dest)令人觉得难以理解！想象一下：如果source或dest是个对象而且它有个operator LPCTSTR()操作符重载呢？例如CString它有个LPCTSTR操作符重载，因此你可以这样
char src[100]
CString dest;
strcpy(src, dest);
这样写没有错，但是楼主，如果你习惯这样写的话你会中招的！例如
class CMyClass
{
      LPVOID p;
      CString s;
public:
      CMyClass() { p = 0x01000; s = _T("test string"); }
      operator LPCTSTR() { return (LPCTSTR)s; }
}CMyClass s;
sprintf("out string message %s", (LPCTSTR)s); // 正确！
sprintf("out string message %s", s); // 你中招了！所以有时候不要去怀疑前辈的做法，可能会暴露你自己的肤浅！他们可能会结合当时的实际情况才会使用这种方法的，而这种方法流行这么多年那肯定会有它的优点。

Answer 28

确实对匈牙利无爱
还是喜欢linux下面那种简介的命名