【问题标题】:Hungarian Notation in FortranFortran 中的匈牙利表示法
【发布时间】:2012-05-21 11:09:30
【问题描述】:

这被认为是好的还是坏的做法?我的一个朋友告诉我,一般来说,现在大多数语言都认为这不是一个好的做法,但他认为他听说 fortran 不是这种情况。这是真的?如果是真的,为什么?

【问题讨论】:

  • 对于“匈牙利符号”的值,.eq. 只是重新编码类型系统,只需省略 implicit none。当然,这绝对是最没用的修饰变量名的方法,但是,嘿嘿!

标签: fortran hungarian-notation


【解决方案1】:

系统匈牙利语

Systems Hungarian 表示法本质上将 type 信息添加到变量名称中,以便您知道正在使用的值的类型,并且不太可能以不正确的方式使用值。这在现代强类型语言中具有可疑的好处,因为类型安全显着降低了错误使用/访问变量的机会。

但是,对于非强类型语言,包括此类信息可能是有益的,因为它可以让程序员不断了解他们正在处理的数据。

对 HN 的最大批评(除了它在强类型语言中的好处有限之外)是使用的类型前缀会导致变量名极其模糊和混乱,因此虽然您可能会获得一定程度的伪类型安全性,您可能会失去代码的清晰度(或者至少创建的代码只有成为您的约定专家才能阅读),这会损害可维护性。

如果您需要按照其他人的命名约定生成代码,那么您几乎没有选择,但是如果您可以控制,您可以定义一个明智、清晰、简单的命名约定,可能会更好地满足您的需求,从而在两者之间取得良好的平衡使变量名信息丰富并引入混乱的混乱。例如,一种做法是以IsOpen 而不是Open 的形式命名布尔变量,以避免在可用作动词和名词的词之间产生混淆。当您将布尔值混合到整数或浮点表达式中时,它还可以很容易地看到。这种方法也很直观,因此任何程序员都无需具备特殊知识即可阅读和理解代码。


Apps 匈牙利语

针对第一条评论,还有另一种形式的匈牙利符号 (Apps Hungarian)。有关它的更深入描述,请参阅 Wikipedia,但本质上它将与变量的 usage用途 相关的信息与其名称相关联,而不是其 输入

在强类型语言中,这是一种更有用的方法,非常值得考虑 - 或者至少在概念上(恕我直言)。我发现选择的前缀往往相当复杂和不友好(例如,rw 在我看来,而不是 row 只是混淆了前缀而没有任何实际收获)。我也认为许多例子是毫无意义的(例如str 表示变量是一个字符串,在许多语言中是多余的,因为字符串通常只以一种形式表示,并且如果变量被合理命名(“UserName”而不是“数据”)通常很明显它是一个字符串)。


现代替代品

在我看来/经验中,通常重要的是澄清变量之间的一些关键区别(例如,我们需要以完全不同的方式对待成员、指针、易失性和常量 - 混合成员和参数或索引数组使用错误的索引变量可能是灾难性的,现代编译器几乎无法保护我们免受这些错误的影响)。如果使用合理的描述性变量命名,列表和字符串之间的区别通常很明显,并且类型安全语言会告诉我们是否混合了这些类型,因此我们不需要前缀。这导致了我自己的极其简单的前缀方法,这在我对this stack overflow question 的回答中进行了解释。

希望这篇文章可以让您在决定前缀是否对您有益时有所思考。最终,您应用的任何前缀方案都必须是您认为(或者更好,可以证明)对您和您的团队有益的东西。不要只是遵循别人的方案 - 想想前缀如何以及为什么有用,并在采用或丢弃它之前客观地评估它。

【讨论】:

  • 既然您提到了系统 HN,提供有关应用程序 HN 的等效问题可能会很有用。
【解决方案2】:

在 30 多年的 Fortran 编程中,我从未遇到过使用匈牙利符号的人。您的朋友可能会混淆 Fortran 长期以来(现在已弃用)根据名称的首字母隐式键入变量的能力。但这早在人们对现在所谓的匈牙利符号的广泛认识之前就已经存在了。

关于在编写 Fortran 时匈牙利表示法是否是或将是采用的好主意这一更普遍的问题,我同意 David,并且(我认为)更广泛的软件开发社区认为它不是非常- 有用的练习。 Fortran 当然不需要它,变量(和其他)名称遵循与许多编程语言非常相似的规则。

【讨论】:

    【解决方案3】:

    这实际上更多地取决于开发环境和团队标准,而不是语言。如果您碰巧使用 Fortran,但在具有代码分析和导航功能的良好 IDE 中,那么您可能不需要 Hungarian Notation。

    我认为真正要问自己的问题是,“匈牙利符号会给我什么?”

    也就是说,它的价值是什么?即使使用旧语言,您仍然可以应用良好的编码实践和技术。保持例程小,变量范围小,等等。现在,我不是 Fortran 专家,所以我不知道有什么限制。但我想它仍然适用。

    当您使用有限的编辑器(例如,在鼠标悬停时没有关于变量的信息)和当您的变量具有相当长的生命周期时,匈牙利表示法特别有用。我的意思是,变量的使用远远超出了它的定义。

    自从很久以前 Fortran 诞生以来,我们作为一个行业已经学到了很多关于组织代码和有效地在开发团队中工作的知识。 (即使团队只有你……请记住,您在几个月前编写的任何代码也可能是由其他人编写的。)您可以将这些经验应用于您的 Fortran 代码。

    使用信息丰富的变量名称。存储并不昂贵,字符不再需要很长时间才能通过调制解调器发送...... 合理的长变量名称是可接受和鼓励的,只要它们传达有关该变量 的信息>意味着。此外,保持变量的使用接近其定义。因此,周围代码的附加上下文揭示了有关变量的更多信息,而不仅仅是其名称。

    简而言之,如果您在整个应用程序中使用了一个名为price 的全局变量,那么调用它dblPrice 表示它是一个双精度变量名称,它会添加有用的信息。但是有更有意义的方法来添加有用的信息。 price首先是一个大范围变量的糟糕名称,如果可能的话,范围可能会变窄。

    【讨论】:

    • 我不使用任何 IDE,我在 vim 中编写代码。我不认为 fortran 有什么好的 IDE...
    • @Nordico Photran 和现在一样好。 abssoft IDE 很棒,但它会让你从 $$$ 中恢复过来。
    猜你喜欢
    • 2012-09-09
    • 2017-02-12
    • 2011-05-03
    • 1970-01-01
    • 2017-03-09
    • 2011-08-27
    • 1970-01-01
    • 2010-11-16
    • 1970-01-01
    相关资源
    最近更新 更多