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