【问题标题】:Variable Naming Conventions For Maps/Lists in Dynamically-Typed languages动态类型语言中地图/列表的变量命名约定
【发布时间】:2010-10-11 23:41:19
【问题描述】:

我正在学习 Groovy 语言,它具有动态类型(以及可选的静态类型)。它还原生支持列表、地图和范围,所以我发现自己经常使用列表和地图,尤其是列表列表、地图列表、列表地图等。

在静态语言(尤其是泛型语言)中,您总是知道自己的类型是什么。我对动态语言相当陌生,要跟踪我的变量应该是什么变得有点困难,所以我想知道其他人是否使用某种变量命名约定来保持这些正确。

例如,假设我有一个日期映射作为键和整数作为值。或整数列表,或包含字符串作为键和帐户对象作为值的映射列表。

似乎在变量名称后面创建一个清晰的约定将帮助我跟踪我正在处理的数据类型结构,而无需查找它。

有什么建议吗?

【问题讨论】:

  • 很遗憾没有能力对 cme​​ts 投反对票。这似乎是一个完全可以接受的问题。
  • @David,评论可以标记为“粗鲁”或“非建设性”。
  • 虽然使用“def”很常见,但Java程序员可能会感到不舒服,而且使用“def”而不是“String”或“Map”确实没有任何优势,除非可能会被取笑Groovy 程序员更关心“风格”而不是下一个阅读他们的代码的人。如果您想知道您的对象是什么类型,如果可能有疑问,请使用实际类型。这也让 IDE 更有帮助(Ctrl-空格补全效果更好)。然而,随着你的进步,有时你可能会觉得 def 更舒服,所以在它看起来合适的时候使用它。通常泛型也可以。

标签: variables groovy language-agnostic naming-conventions dynamic-typing


【解决方案1】:

随着时间的推移,你会逐渐适应这种情况。不是说我不认识一个用了 20 年的程序员还在使用匈牙利语,而是他用静态类型语言编写代码,所以几乎可以理解。

考虑一下。您命名的那个变量可能是一个 HashMap,那么您在名称中添加什么类型?地图?这是一个中间的答案。为什么不收藏?由于这种方式,如果您决定更改数据存储方式,则不必更改变量名称。如果你真的想让读者知道发生了什么,为什么不使用 HashMap。

您可能会怀疑,这些都不是必需的。动态语言(甚至多态性)的要点是您不需要知道所呈现变量的确切类型,只有数据本身很重要。虽然您可能需要有关如何与该数据交互的提示,但您很快就会发现在大多数情况下您已经知道,或者可以轻松地将这些信息放入变量中而无需指定类型:addressesByZipCode、totalByBirthdate 等。

【讨论】:

    【解决方案2】:

    动态语言的一个好处是,即使您将对象用作地图 - 它也不一定是地图。它所要做的就是支持发送给它的任何消息。在 Groovy 中,如果我知道给定方法需要一个映射,以便它可以通过字符串键查找事物 - 我可以给它完整映射、精简映射、具有与键命名相同的属性的 Expando ,或任何其他具有与键名称相同的属性的对象。这是因为 someObject["keyname"] 和 someObject.keyname 是同一个东西。 (当然,如果代码调用 someObject.get("keyname") 我必须以某种方式连接该方法。)

    关键是,在像 Groovy 这样的动态语言中,您较少考虑 TYPES,而更多地考虑 SUPPORTED MESSAGES。如果它在概念上是一张地图,很好 - 将其命名为birthdateToTotal 是有道理的(虽然我更喜欢称它为'totals',因为totals[birthdate] 看起来比birthdateToTotal[birthdate] 更好) - 但如果它不需要指定,不要指定它。稍后您会留出灵活性。

    【讨论】:

      【解决方案3】:

      在静态语言(尤其是泛型语言)中,您始终知道自己的类型是什么。

      在使用动态语言编程一段时间后,您会了解到以这种方式使用类型是一种拐杖。两条建议:

      1. 使用良好的变量命名。例如,如果您有一个日期到整数的映射,您可以将其命名为 BirthdateToTotalLookup。
      2. 了解要寻找的视觉线索。这似乎很明显,但我花了一段时间才养成这样寻找线索的习惯:

        sum += x['10-16-92']
        

      从上面的代码中,我可以看出 x 是一个以日期为键并返回某种数字的映射。

      【讨论】:

        【解决方案4】:

        变量的名称应该向阅读代码的人解释它应该是什么,它代表什么。如果您有一个日期到整数的映射,它是否表示,例如(建议的变量名称在括号中):

        1. 在该日期到期的付款次数 (paymentsDue)
        2. 映射日期与其他时间点之间的天数 (daysPassed)
        3. 当天在 Stack Overflow (numberOfPostedMessages) 上发布的大量消息

        在变量类型不容易获得的语言中,您可能需要附加一个后缀前缀,例如paymentsDueMap。但是,我建议不要在变量名中编码任何额外的类型信息,例如datesToInts——这通常弊大于利。

        最后,如果您有一个复杂的数据结构,例如字符串和帐户之间的映射列表,最好将其封装到一个单独的类中,并根据其意图命名。

        【讨论】:

          【解决方案5】:

          如果名称可以保持简短,那么我倾向于将地图命名为“nounToNoun”之类的名称。因此,使用您将日期映射到整数的示例,我将其命名为“dateToCount”(如果整数是某些东西的计数器)。这样就很明显它是一张地图,并且很明显什么被映射到什么。问题是有时很难使这些名称保持简短易读。例如,“userToLoginHistory”开始变得有点笨拙。

          对于列表,我通常使用复数作为变量名。所以“user”是单个用户,“users”是一个用户列表。

          老实说,我不确定地图列表的好名称是什么。

          【讨论】:

            【解决方案6】:

            这是一个常见的初学者的感叹。您可以使用命名约定,但很可能您很快就会放弃它并专注于 变量表示的内容(它相对于其余代码的含义)而不是担心 它是如何表示的(它是“类型”)。

            【讨论】:

            • 这是一个非常古老的问题,我知道,但对我自己而言,我对 如何 变量的表示方式并不感兴趣,因为它能够一目了然地确定, 上面有哪些操作可用。例如,我可能不在乎某个东西是数组还是列表,但我确实关心是否可以迭代它。在这种情况下,约定怎么样?例如。 “名称列表”与“名称”?
            猜你喜欢
            • 1970-01-01
            • 2021-07-29
            • 1970-01-01
            • 1970-01-01
            • 1970-01-01
            • 2010-09-19
            • 1970-01-01
            • 1970-01-01
            • 1970-01-01
            相关资源
            最近更新 更多