Bro*_*k D 33 self-documenting-code conventions hungarian-notation
是值得学习惯例还是可读性和可维护性的祸害？
ang*_*son 57
考虑到大多数使用匈牙利表示法的人都遵循误解的版本,我会说这是毫无意义的.
如果你想使用它的原始定义,它可能更有意义,但除此之外它主要是语法糖.
如果你阅读关于这个主题的维基百科文章,你会发现两个相互矛盾的符号,系统匈牙利表示法和Apps匈牙利表示法.
原始的,好的定义是Apps匈牙利表示法,但大多数人使用匈牙利语系统表示法.
作为两者的一个例子,考虑用l表示长度的前缀,a表示区域,v表示音量.
使用这种表示法,以下表达式是有意义的:
int vBox = aBottom * lVerticalSide;
但这不是:
int aBottom = lSide1;
如果你混合前缀,它们将被视为等式的一部分,而volume = area*length对于一个盒子来说很好,但是将长度值复制到一个区域变量应该引起一些红旗.
不幸的是,另一种表示法没那么有用,人们在变量名前加上值的类型,如下所示:
int iLength;
int iVolume;
int iArea;
有些人用n代表数字,或者i代表整数,f代表浮点数,s代表字符串等.
原始前缀旨在用于发现方程中的问题,但以某种方式转变为使代码更容易阅读,因为您不必去寻找变量声明.使用今天的智能编辑器,您可以简单地将鼠标悬停在任何变量上以查找完整类型,而不仅仅是它的缩写,这种类型的匈牙利符号已经失去了很多意义.
但是,你应该自己决定.我只能说我也没用.
编辑只是为了添加一个简短的通知,虽然我不使用匈牙利表示法,但我确实使用了前缀,它是下划线.我使用_作为类的所有私有字段的前缀,否则拼写它们的名称,因为我将属性,标题为首字母大写的标题.
Wed*_*dge 22
如果使用正确,匈牙利命名惯例会很有用,不幸的是,它往往会被滥用.
阅读Joel Spolsky的文章" 使错误的代码看错"以获得适当的观点和理由.
本质上,基于类型的匈牙利表示法,其中变量以关于其类型的信息为前缀(例如,对象是字符串,句柄,int等)通常是无用的,并且通常仅增加开销而几乎没有任何好处.遗憾的是,这是大多数人都熟悉的匈牙利符号.但是,设想的匈牙利符号的意图是添加有关变量包含的"种类"数据的信息.这允许您将来自其他类型数据的各种数据分区,除非可能通过某些转换过程,否则这些数据不应该被混合在一起.例如,基于像素的坐标与其他单位中的坐标,或不安全的用户输入与来自安全来源的数据等.
以这种方式看待它,如果您发现自己通过代码查找变量信息,那么您可能需要调整命名方案以包含该信息,这是匈牙利惯例的本质.
请注意,匈牙利表示法的替代方法是使用更多类来显示变量用法的意图,而不是依赖于各地的原始类型.例如,不是为不安全的用户输入提供变量前缀,而是可以为不安全的用户输入提供简单的字符串包装类,为安全数据提供单独的包装类.在强类型语言中,这具有编译器强制执行分区的优点(即使在类型较弱的语言中,您通常可以添加自己的tripwire代码),但增加了不小的开销.
Jon*_*jap 14
当涉及UI元素时,我仍然使用匈牙利表示法,其中几个UI元素与特定对象/值相关,例如,
标签对象的lblFirstName,文本框的txtFirstName.我绝对不能将它们都命名为"FirstName",即使这是两个对象的关注/责任.
其他人如何处理命名UI元素？
这是毫无意义的(并且分散注意力),但在我的公司中使用相对较多,至少对于像int,字符串,布尔值和双打这样的类型.
之类的东西sValue,iCount,dAmount或者fAmount,和bFlag随处可见.
曾几何时,这个会议有充分的理由.现在,它是一种癌症.
我认为匈牙利符号是一条有趣的脚注,沿着"路径"提供更易读的代码,如果做得恰当,最好不要这样做.
尽管如此,我宁愿废除它,而不是这样:
int vBox = aBottom * lVerticalSide;
写这个:
int boxVolume = bottomArea * verticalHeight;
这是2008年.我们没有80个字符的固定宽度屏幕了!
另外,如果你编写的变量名远远超过你应该考虑重构为对象或函数的变量名.
这些天不是范围更重要,例如
使用现代技术重构旧代码,搜索和替换符号因为你改变了它的类型是繁琐的,编译器将捕获类型更改,但通常不会捕获不正确的范围使用,合理的命名约定在这里有所帮助.