Nor*_*ico 1 fortran hungarian-notation
它被认为是好的还是坏的做法?我的一位朋友告诉我,一般来说,现在大多数语言都不被认为是好习惯,但是他认为他听说这不是fortran的情况.这是真的?如果是真的,为什么?
在Fortran的30多年编程中,我从来没有遇到任何使用匈牙利符号的人.您的朋友可能会混淆Fortran长期(现已弃用)的能力,根据其姓名的首字母隐式输入变量.但是,很久以前人们普遍意识到现在所谓的匈牙利符号.
关于匈牙利符号在编写Fortran时是否或将会是一个好主意的更普遍的问题,我同意David,并且(我认为)更广泛的软件开发社区认为它是一个非常有用的实践.Fortran肯定不需要它,变量(和其他)名称遵循与许多编程语言非常相似的规则.
系统匈牙利语
系统匈牙利表示法实质上是将类型信息添加到变量名称中,以便您了解所使用的值的类型,并且不太可能以不正确的方式使用值.这在现代强类型语言中具有可疑的好处,因为类型安全性显着降低了错误地使用/访问变量的机会.
但是,对于不太强类型的语言,包括这种信息可能是有益的,因为它使程序员不断了解他们正在处理的数据.
对HN的最大批评(除了它在强类型语言中的有限的好处)是使用的类型前缀可能导致极其模糊和混乱的变量名称,所以虽然你可以获得一些伪类型安全措施,你可能会失去代码中的清晰度(或至少创建只能在您的约定中可读的代码),这可能会损害可维护性.
如果您需要为其他人的命名约定生成代码,那么您别无选择,但如果您掌控,您可以定义一个合理,清晰,简单的命名约定,以便更好地满足您的需求,在创建变量名称之间取得良好的平衡信息丰富,引入混乱的混乱.例如,一种做法是以形式IsOpen而不是命名布尔变量Open,以避免可以用作动词和名词的单词之间的混淆.它还可以让您轻松查看何时将布尔值混合为整数或浮点表达式.这种方法也可以直观地工作,因此任何程序员都无需特殊知识即可阅读和理解代码.
应用匈牙利语
在回应第一条评论时,还有另一种形式的匈牙利表示法(Apps匈牙利语).有关它的更深入描述,请参阅Wikipedia,但实质上它将与变量的用法或用途相关的信息与其名称相关联,而不是与其类型相关联.
在强类型语言中,这是一种更有用的方法,值得考虑 - 或至少(恕我直言)的概念.我发现所选择的前缀往往是相当复杂和不友好的(例如,rw而不是row我的想法只是模糊前缀而没有任何实际的好处).我也认为很多例子都是毫无意义的(例如,str为了表明变量是一个字符串,在许多语言中都是多余的,因为字符串通常只用一种形式表示,如果变量被明确命名("UserName"而不是"Data") )它通常很明显,它将是一个字符串).
现代选择
在我看来/经验中,通常重要的是澄清变量之间的一些关键差异(例如,我们需要将成员,指针,挥发物和常量彼此完全不同 - 混合成员和参数或将数组索引为错误索引变量可能是灾难性的,而现代编译器对保护我们免受这些错误的影响很小.如果使用合理的描述性变量命名,则列表和字符串之间的区别通常是显而易见的,并且类型安全语言将告诉我们是否将这些类型混合起来,因此我们不需要这些情况的前缀.这导致了我自己非常简单的前缀方法,这在我对这个堆栈溢出问题的回答中有所解释.
希望这篇文章在决定前缀是否对您有益时可以给您一些思考.最终,您应用的任何前缀方案都需要是您认为(或更好,可以证明)对您和您的团队有益的事情.不要只关注别人的方案 - 考虑前缀如何以及为什么有用,并在采用或丢弃它之前客观地评估它.
| 归档时间: |
|
| 查看次数: |
238 次 |
| 最近记录: |