我正在学习 Groovy 语言，它具有动态类型（以及可选的静态类型）。它还原生支持列表、地图和范围，所以我发现自己经常使用列表和地图，尤其是列表列表、地图列表、列表地图等。
在静态语言中（尤其是泛型语言），你总是知道你的类型是什么。我对动态语言相当陌生，要跟踪我的变量应该是什么变得有点困难，所以我想知道其他人是否使用某种变量命名约定来保持这些正确。
例如，假设我有一个日期映射作为键和整数作为值。或整数列表，或包含字符串作为键和帐户对象作为值的映射列表。
似乎在变量名后面创建一个清晰的约定将帮助我跟踪我正在处理的数据类型结构，而无需查找它。
有小费吗？
这是一个常见的初学者的感叹。您可以使用命名约定，但很可能您很快就会放弃它并专注于变量表示的内容（它相对于其余代码的含义）而不是担心它是如何表示的（它是“类型”） .
变量的名称应该向阅读代码的人解释它应该是什么，它代表什么。如果您有日期到整数的映射，它是否表示，例如（建议的变量名称在括号中）：
paymentsDue)daysPassed)numberOfPostedMessages)上发布的一些消息在变量类型不容易获得的语言中，您可能需要附加后缀的前缀，例如paymentsDueMap. 但是，我建议不要在变量名中编码任何额外的类型信息，例如datesToInts- 这通常弊大于利。
最后，如果您有一个复杂的数据结构，例如字符串和帐户之间的映射列表，最好将其封装到一个单独的类中，并根据其意图命名。
在静态语言中（尤其是泛型语言），你总是知道你的类型是什么。
在使用动态语言编程一段时间后，您会了解到以这种方式使用类型是一种拐杖。两条忠告：
了解要寻找的视觉线索。这似乎很明显，但我花了一段时间才养成寻找这样的线索的习惯：
sum += x['10-16-92']
从上面的代码中，我可以看出 x 是一个以日期为键并返回某种数字的映射。
如果名称可以保持简短，那么我倾向于将地图命名为“nounToNoun”之类的名称。因此，使用您将日期映射到整数的示例，我将其命名为“dateToCount”（如果整数是某些东西的计数器）。这样就很明显它是一张地图，并且很明显什么被映射到什么。问题是有时很难使这些名称保持简短易读。例如，“userToLoginHistory”开始变得有点笨拙。
对于列表，我通常使用复数作为变量名。所以“用户”将是单个用户，“用户”将是用户列表。
老实说，我不确定地图列表的好名字是什么。
这是你会随着时间的推移而超越的东西。并不是说我不认识一个 20 年仍在使用匈牙利语的程序员，但他正在使用静态类型语言进行编码，因此几乎可以理解。
考虑一下。您命名的那个变量可能是一个 HashMap，那么您在名称中添加什么类型？地图？这是一个中间的答案。为什么不收藏？由于这种方式，如果您决定更改数据存储方式，则不必更改变量名称。如果您真的想让读者知道发生了什么，为什么不使用 HashMap。
您可能会怀疑，这些都不是必需的。动态语言（甚至多态性）的要点是您不需要知道所呈现变量的确切类型，只有数据本身很重要。虽然您可能需要有关如何与该数据交互的提示，但您很快就会发现在大多数情况下您已经知道，或者可以轻松地将这些信息放入变量中而无需指定类型：addressesByZipCode、totalByBirthdate 等。
动态语言的好处之一是，即使您将对象用作地图 - 它也不必是地图。它所要做的就是支持发送给它的任何消息。在 Groovy 中，如果我知道给定方法需要一个映射，以便它可以通过字符串键查找事物 - 我可以给它完整映射、精简映射、具有与键命名相同的属性的 Expando ，或任何其他具有与键名称相同的属性的对象。这是因为 someObject["keyname"] 和 someObject.keyname 是同一个东西。（当然，如果代码调用 someObject.get("keyname") 我必须以某种方式连接该方法。）
关键是，在像 Groovy 这样的动态语言中，您较少考虑 TYPES，而更多地考虑 SUPPORTED MESSAGES。如果它在概念上是一张地图，很好 - 将其命名为birthdateToTotal 是有道理的（虽然我更喜欢称它为'totals'，因为totals[birthdate] 看起来比birthdateToTotal[birthdate] 更好） - 但如果它不需要指定，不要指定它。你以后给自己留灵活性。