love in C++, live on MFC

to get ready...

C++博客 首页 新随笔 联系 聚合 管理
  47 Posts :: 0 Stories :: 97 Comments :: 0 Trackbacks

书上说匈牙利命名法已经过时了,我不这样认为。

有人认为现在编译器已经可以很好的检测出类型的不匹配,或者IDE中可以很快的看到类型,所以在c中可能需要,在C++(强类型语言)中就不需要了。
C++ made it harder to do that without wicked casting and the compiler catches most of those kind of errors.  So, I agree with the previous poster that it's now redundant.
Also, modern IDEs allow you to hover the cursor over a variable and show you the variable's definition.


不过我觉得代码不是写给编译器看的,而是写给人看的,这里就有self-documenting和readability的问题。
很明显,如果你看到nIndex 或者strFile或者wndNext,就可以很快知道分别是int CString CWnd类型,而不用回头去看变量定义,这样,看代码时就会很快。
而且,对于MFC程序员来说,更重要一些,因为MFC里面的变量都是用匈牙利命名法的。
If you're programming C++/MFC you're better sticking to hungarian for consistency with the class library & Win32 API declarations.
微软的约定,就是标准了

不过,书上提到在泛型编程中不需要,现在体会还不深,可能是对的。

今天(2006 04 13碰巧看到codeproject的一个vote),结果如下

Option Votes %
Pascal Cased 171 10.6
camel Cased 702 43.4
Fixed letter prefix (eg lLocal) 81 5.0
Hungarian prefix (eg strLocal) 481 29.7
Scope prefix (eg l_Local) 36 2.2
Scope and Hungarian prefix (eg l_strLocal) 125 7.7
Responses 1618

Hungarian Notation排第二.
cp上面有两个链接
Conversations: Hungarian wartHogs (http://www.cuj.com/documents/s=7989/cujcexp1911hyslop/hyslop.htm)
号称这篇文章就已经明白的说HN过时了(作者也是c++ coding stardard的作者).
如果不用HN,那么应该用什么样的命名规则呢?
Naming Guidelines(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconNamingGuidelines.asp)
.Net下的推荐,也许别的地方也可以用.
posted on 2006-04-05 19:45 flyingxu 阅读(530) 评论(5)  编辑 收藏 引用 所属分类: C++ Coding Standards

Feedback

# re: Is Hungarian notation obsolete? 2006-04-07 10:20 小明
对于变量命名,我的原则就是入乡随俗

写MFC程序就用匈牙利
写Java程序就用Java命名
写Linux程序大部分都用小写和下划线
改别人的程序就按别人的标准

总之,目标是使代码看起来是一个人写的。  回复  更多评论
  

# re: Is Hungarian notation obsolete? 2006-04-11 16:11 ace
编码规范要看你是站在哪层面上来看.
如果全是VC+MFC,那用Hungarian style的就足够了.

但是,我以前也是Hungarian的"支持"者,但后来发现它有太多的与编码规范其它条款抵触的地方.现在我也不支持它了.

清晰、可理解的 C++ 源代码是规则和指南的主要目标:清晰、可理解的源代码是软件可靠性和可维护性的主要作用因素.
清晰、可理解的代码可以表示为以下三个简单的基础原理
最小混淆 - 它的生存期中,源代码的读远比写多,规约更是这样。理想情况下,源代码读起来应该象英语一样描述了所要做的事,这同时还带来了它执行的好处。程序更多是为人编写,而不是为计算机而编写。阅读代码是一个复杂的脑力过程,它可由统一标准来简化,在本文中还指最小混淆原则。整个项目中统一样式是软件开发团队在编程标准上达成一致的主要原因,它不应视为一种惩罚或对创造性和生产力的阻碍。
维护的唯一点 - 只要可能,设计决策就应在源中只表述一点,它的多数后果应程序化的派生于此点。不遵守这一原则严重损害了可维护性、可靠性和可理解性。
最小干扰 - 最终,应用最小干扰原则(它是易读性的主要作用因素)。即,避免将源代码与可视干扰(如内容较少或对理解软件目的不起作用的信息)相混合:

去年得了jolt大奖的 C++ Coding Standards 一书
http://www.huachu.com.cn/2006/c++.htm

也把Hungarian 样式的风格作了批评.


  回复  更多评论
  

# re: Is Hungarian notation obsolete? 2006-04-13 16:20 flyingxu
@ace
很感兴趣你回复中的观点,能有具体例子说明一下吗?

估计HN真的正在慢慢的过时,在codeproject中的一个vote中,HN排第二.
http://www.codeproject.com/script/survey/detail.asp?survey=554
  回复  更多评论
  

# re: Is Hungarian notation obsolete? 2006-04-14 09:57 Stone Jiang
@flyingxu
有空多交流这个话题,我要整理之后才能给出一个自已觉得满意点的回复.
晚些时候再来个详细的.   回复  更多评论
  

# re: Is Hungarian notation obsolete? 2006-05-12 09:13 ztwaker
我赞成小明的意见。  回复  更多评论
  


只有注册用户登录后才能发表评论。
【推荐】超50万行VC++源码: 大型组态工控、电力仿真CAD与GIS源码库
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理