C# 字典的命名约定答案

【问题标题】：Naming convention for a C# DictionaryC# 字典的命名约定
【发布时间】：2010-12-02 00:54:18
【问题描述】：

我们如何命名字典变量？

假设在我的方法中我有Dictionary<string, List<string>> dictionary;，其中dictionary 的键是国家名称，值是省/州名称列表。我应该如何重命名dictionary？

我知道我们可以为这个例子创建一个Country 类。但请不要提及这个替代方案，因为我在这里考虑好的命名约定。

【问题讨论】：

您可以将字典视为映射函数，或者您可以将其更具体地视为散列/查找/索引函数。映射更通用。考虑一个将摄氏温度映射到华氏温度的数学函数，它可以命名为 ConvertCelsiusToFarenheit。 “To”强调输入空间/集合是焦点。 Y-By-X 更好地捕捉到字典是一种使用基于集合的散列的特定类型的映射。 “By”强调输出空间/集合是焦点。除非它可以解锁某些东西，否则钥匙一文不值。只是我的看法，但我希望它有助于提供一些见解。
另一个快速说明，你想捕捉它的用途，而不是它的作用：真正的字典是用来按单词查找定义的。确实，它将一些词映射到它们的定义，但这也不能捕捉意图。

【解决方案1】：

ProvincesByCountry

【讨论】：

是否有一些参考资料说 ValueByKey 是 C# 中命名字典的标准？似乎有许多同样好的字典命名约定。 C# 社区是否只是在没有任何规范参考的情况下接受了 ValueByKey（可能跟随微软的领导）？
据我所知，这不是一个既定的惯例。对于手头的案子，这似乎是一个很好且简洁的解决方案。
我认为这是因为 FooByBar 使得将 Map 或 Dictionary 附加到名称中是多余的。我认为 By 和 To 之间的区别在于 By 意味着您将某事物的 id/key/field 映射到事物本身，而 To 意味着您将两个类似复杂的对象相互映射。如果集合类似于查找但只有一个值，那么我会使用 By。如果集合类似于语言词典，那么我会使用 To。
感谢您。光滑的解决方案。我害怕以dictionary/Map 结尾，这太完美了。
在某些情况下，我们可以使用Per 而不是By。例如：RulesPerTenant

【解决方案2】：

我主要使用其中一种：

【讨论】：

【解决方案3】：

我喜欢XtoYMap 或YFromX。

【讨论】：

【解决方案4】：

ProvincesByCountry 不够明确，因为这听起来像是一对一地映射国家和省份。在访问 ProvincesByCountry["Germany"] 时，我会假设一个值是一个对象而不是对象列表。

我个人的模式也差不多：

[Plural of a noun describing the value]By[Singular of a noun describing the key]

但是，如果描述值的名词本质上是复数，那么我使用后缀 arrays 或 lists，因为在英语中你不能真的“复数”复数。我个人总是坚持使用 arrays，不管我使用的是 IEnumerable 还是 IEnumerable 的实际实现，就是列表，或数组或其他。

在你的情况下，它变成：

ProvinceArraysByCountry

以科学的精确度告诉它是什么。

如果有字典作为值，我会递归地应用此规则。然后访问顺序与名称中的单词顺序相反。假设您添加了行星：

ProvinceArraysByCountryByPlanet["Earth"]["Germany"][0] = "Bavaria"
ProvinceArraysByCountryByPlanet["Earth"]["Germany"][1] = "Rhineland-Palatinate"

最后是这里的最后一点。如果这样的字典映射对象属性和对象本身，那么我会在关键部分省略描述对象的单词。这就是我的意思：

NodesByIndex[node.Index] = node; // - Do
NodesByNodeIndex[node.Index] = node; // - Don't

我无条件地使用这种模式，这很好，因为它绝对没有猜测的余地。缺点是它有时会生成相当长的名称。但我不知道如何始终使用明确但始终简短的名称。你总是不得不妥协。这当然是一个品味问题。

当键也是字典或者当你有字典列表的字典列表或其他一些疯狂的异国情调时，这种模式不起作用（或者至少你会打破你的大脑）。但我不记得有这么多层次的嵌套，所以我很满意。

【讨论】：

代码完成和宽监视器对有意义的变量名来说是一个巨大的福音
正如我在微软的源代码中看到的，他们使用Collection 后缀。所以我会说ProvinceCollectionsByCountry 或者更专业的名称：ProvinceCollectionsByCountryName。

【解决方案5】：

命名总是与上下文相关的。因此，在这种特定情况下，一些指定国家到州映射的名称是合适的。

如果这只是一个在更大的上下文中循环的设备然后被丢弃，我通常只使用一个短的临时类型 var，比如...

var dict = GetCountryStateMapping();
foreach(var item in dict)
{
  //Something....
}

【讨论】：

让我想起了一个 IT 笑话……“计算机科学中只有 2 个难题，命名、缓存失效和 Off by 1 个错误。”
好的。但是，如果我想将其用作属性怎么办？
啊，那么在这种情况下，你有一个上下文和一个范围，父类（连同内容）和它的生命周期。在这种情况下，命名要容易得多。正如我所说，命名总是与上下文相关的。在这种情况下，RegionByCountry 或 StateByCountry 或 ProvinceByCountry 等将是最合适的 IMO。

【解决方案6】：

省、省地图、省字典

全部浮现在脑海中。我喜欢我自己的省地图。如果它是一个成员字段，我会添加一个“m_”前缀，如“m_provinceMap”。

【讨论】：

好的。但这并不能反映密钥。
我同意。在这种情况下，它应该是非常隐含的。我会选择更短的名称，除非有原因导致键可能不明确。如果您有多个包含省份的地图，那么区分键将很重要。在你的例子中，你没有歧义。
嗯...我对省地图、省字典没问题。但省份似乎是一个 List. 的名称