属性“ID”的正确命名约定是什么：ID或Id？
https://stackoverflow.com/questions/264823
-
06-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian题
非常简单的问题：当我有一个可持久的对象时，它通常有一个名为ID的属性（用于抽象类）。
那么..是命名约定ID还是Id？
例如
public int ID { get; set; }
或
public int Id { get; set; }
PS。这适用于.NET btw。 FXCop conformat将是一个奖金。
解决方案
我通常使用 Identifier 。如果我真的想保持简短（例如，作为较长标识符的一部分），我使用Id，除非它是参数或私有成员。
.NET Framework命名指南说明了这一点：
首字母缩略词是由术语或短语中的单词字母组成的单词。例如，HTML是Hypertext Markup Language的首字母缩写。只有在众所周知且易于理解的情况下，才应在标识符中包含首字母缩略词。缩略语与缩写的不同之处在于缩写缩短了单个单词。例如，ID是标识符的缩写。通常，库名称不应使用缩写。
可以在标识符中使用的两个缩写是ID和OK。在Pascal标识的标识符中，它们应显示为Id，然后显示。如果用作驼峰标识符中的第一个单词，它们应分别显示为id和ok。
其他提示
无论你喜欢什么，只要保持一致。 ID不是单词，它是身份的缩写。如何写缩写是人们长期争论的问题。例如。是吗
getResourceURL
或
getResourceUrl
实际上两者都可以在不同的框架中使用。另一个流行的abbr。有类似问题的是UTF8。
保持一致非常重要，因为否则人们总是必须为每个方法查找正确的大小写，如果每个方法都以不同的方式处理它。
我有自己的约定。如果abbr。在名称的末尾，它全部大写，如果它在其他地方，它遵循骆驼符号规则。 E.g。
getResourceURL
urlOfResource
compareUrlToString
为什么呢？我喜欢abbr。资本化。大多数人都希望URL或UTF大写。但是，如果在名称的中间，它会破坏骆驼表示法的优点。骆驼表示法的优点是你可以通过大写来查看新单词的起始位置。所以比较一下：
compareURLToString
compareUrlToString
在第一种情况下，我没有立即看到URL是一个单词而To是下一个单词。 T可能是URL（URLT）的一部分，并且是不同的缩写，因此我将使用第二种形式。如果它在最后，它将不起作用，没有其他单词，因此我更喜欢大写形式。我在所有代码中坚持这个惯例。
指南说“Id”。
幸运的是，.Net人员非常友好地给我们提供了“命名指南”。而不是“命名法律” ;），所以基本上如果你强烈认为打破指南规则确实增加了比跟随它更多的价值，那么无论如何打破它，如果他们理解你的理由（如它提供更多的可读性和强调，没有人会让你对它负责）名称的含义）
在我的商店，我们使用'ID'，即使指南说'Id'，但没有人，真的对此感到内疚。
正如其他人所指出的，根据.NET惯例，Id是正确的，但不知何故它感觉不对，所以很多人使用ID（并且仍然存在）。
我不知道你的字段的内容是什么（数字，字符串，guid），但如果你想跳过这个问题，你可以简单地使用另一个.NET约定来识别对象：名称
我们在内部使用ID，因为Id在我看来就像心理学一样，但是FxCop抱怨，因为ID不是首字母缩略词，它是缩写（用于身份/标识符）。根据FxCop规则，只允许两个字符长的首字母缩略词全部大写。其他一切都应该是正确的案例。
我们在ID属性上放置了一个SuppressMessage属性，每个人都很高兴。
＆QUOT; ID＆QUOT;是FxCop命名规则中硬编码的缩写之一，即使它们是其他单词的一部分，也总是被认为是拼写错误的。我发现覆盖它的唯一方法是添加“ID”。缩写为（）：
<Dictionary>
<Acronyms>
<CasingExceptions>
<Acronym>ID</Acronym>
</CasingExceptions>
</Acronyms>
</Dictionary>
它适用于FxCop 1.36。 附：一般来说，我认为“Id”是一个更好的选择，但有时如果根据我们无法控制的XML文件（或Web服务）生成名称，则无法更改名称
我更喜欢ID，也喜欢与其他单词（例如CustomerID）结合使用，但严格来说这是违反常规命名约定的。
我们在这里看到像“Id”这样的东西。或其他首字母缩写词作为单词，和“Id”。很容易，因为在银行业务中我们会得到很多奇怪的字母组合。因此，我们将其视为一个词，只有首字母大写，这就是我们最终在内部编码惯例文件中定义的方式。
但最重要的是：选择哪种约定更适合开发人员团队和其他查看源代码并坚持使用它的人。
