是否建议为所有 C# 枚举添加“Enum”后缀以避免命名冲突？答案

【问题标题】：Is it recommended to suffix all C# enums with "Enum" to avoid naming conflicts?是否建议为所有 C# 枚举添加“Enum”后缀以避免命名冲突？
【发布时间】：2009-05-28 12:32:41
【问题描述】：

This stackoverflow question 有一个有趣的讨论，关于如何避免给枚举和属性赋予相同的名称，这样你就没有这样的代码：

public SaveStatus SaveStatus { get; set; }

似乎已接受的答案建议对枚举使用“状态”，对属性使用“状态”：

public SaveStatus SaveState { get; set; }

但我认为这很难阅读，并且不能立即清楚什么是什么。

由于这个枚举命名问题是一个持续存在的问题，我正在考虑总是给我的枚举添加“枚举”后缀，所以我会这样：

public SaveStatusEnum SaveStatus { get; set; }

SaveStatus = SaveStatusEnum.Succeeded;

有人这样做吗？满意吗？用另一种方式解决了这个问题？

【问题讨论】：

MS IDE 在 DOTNET 中开发的要点之一就是消除此类问题。我什至会说 IDE 是 DOTNET 不可或缺的一部分。
我这样做了，我很满意。我曾经避免它，但它在实际代码中给我带来了问题。当您查看一行代码时，使用 SaveStatus SaveStatus { get; 似乎是合理的。放; }。当你在一个有数百行的课程中并且 resharper 不断混淆这两者时，这很烦人而且令人困惑。
是的，但这是 ReSharper 错误，而不是 Visual Studio 或编译器问题。告诉 ReSharper 团队修复他们的错误。 jetbrains.net/jira/browse/RSRP-83171

标签： c# enums naming-conventions

【解决方案1】：

来自MSDN page for Property naming guidelines：

考虑创建一个与其底层同名的属性类型。例如，如果您声明一个名为 Color 的属性，则该属性也应该是 Color。

我认为这是“不”:)

编辑：

如果您不喜欢在声明属性的类中使用完全限定名称，您可以解决它：

using SaveStatusEnum = MyNamespace.SaveStatus;
...
SaveStatus = SaveStatusEnum.SomeValue;

这样您就可以保留不带后缀的枚举名称，并将奇怪的命名限制在一个类中。 :)

【讨论】：

是的，但是当我的类文件中有枚举时，这会导致命名冲突。当我想要枚举时，我必须始终使用完整的命名空间，因为 VisualStudio intellisense 总是认为我的意思是属性。 SaveStatus = TestingDelegateCommandSave.ViewModels.SaveStatus.NotApplicable;
好的，我收回它，它适用于智能感知（我有一些旧的 ...Enum 代码）。好的。这是我一直在寻找的答案，具有决定性意义。从现在开始，我将我的枚举命名为与我的属性相同的名称。
实际上，编译器也可能会抱怨它——我只是在我的实际项目中尝试了一个示例。如果发生这种情况，您可以使用 using 语句解决它（我用一个示例更新了我的答案）。
如果 VisualStudio 可以接受，那么我可以接受：当我输入“SaveStatus = SaveStatus.NotApplicable”时，intellisense 首先为我提供属性，然后是枚举。
该语言有许多精心设计的规则来启用这种场景（我们称之为“颜色场景”），但实际上，在某些情况下，歧义是不可避免的。有关详细信息，请参阅 C# 3.0 规范的第 7.4.5.1 节“相同的简单名称和类型名称”。

【解决方案2】：

.net 框架是否使用 Enum 作为后缀？ No.所以我也不用它。

相反，我使用 Option（如果是 Flags-Enum 则使用 Options）、Mode 或类似的词。

public SaveStatusMode SaveStatus { get; set; }
public SaveStatusOption SaveStatus { get; set; }
public SaveStatusVariant SaveStatus { get; set; }

【讨论】：

【解决方案3】：

Microsoft 的 .NET 命名指南没有给出任何此类建议。

为什么要避免给枚举和属性赋予相同的名称？这个：

public SaveStatus SaveStatus { get; set; }

工作得很好，可读，并且非常容易被发现和使用。

【讨论】：

但是在我的构造函数中我必须有一个巨大的命名空间限定符： SaveStatus = TestingDelegateCommandSave.ViewModels.SaveStatus.NotApplicable;否则智能感知认为我的意思是“SaveStatus”属性。我在我的类文件中定义了枚举，因为它仅用于我的类，因此与属性的命名冲突这就是为什么我正在寻找另一种命名枚举的约定，以避免这种情况。
我一直使用 SaveStatus SaveStatus。由于它是一个属性，我认为比将名称更改为 SaveState 更具可读性。我永远不会使用枚举的东西。
@Edward：不，您不需要命名空间限定符，至少在 C# 中不需要。 "SaveStatus = SaveStatus.NotApplicable" 工作得很好。
Microsoft 的 .NET 命名指南建议不要使用“Enum”作为后缀。 msdn.microsoft.com/en-us/library/4x252001(v=vs.71).aspx
@jessegavin，我知道，这正是我在回答中所说的。

【解决方案4】：

一种后缀用于某些类型的类，例如xxxException 和xxxAttribute 类，但后缀并未广泛使用。例如，实现 IEnumerable 的类不命名为 MyListEnumerableClass，而只是命名为 MyList。

与其发明一个使名称混乱的标准后缀，不如尝试编造在特定情况下有意义的名称。

【讨论】：

【解决方案5】：

我知道我的建议违反了 .NET 命名约定，但我个人在枚举前面加上“E”，在枚举标志前面加上“F”（类似于我们在接口前面加上“I”的方式）。我真的不明白为什么这不是惯例。枚举/标志是一种特殊情况，例如永远不会改变其类型的接口。它不仅清楚地说明了它是什么，而且很容易输入智能感知，因为前缀将过滤大多数其他类型/变量/等，并且您不会遇到这些命名冲突。

这也将解决另一个问题，对于 WPF 中的示例，它们使用静态类，例如具有预定义类型实例的枚举（例如 FontWeights），但如果不搜索它，您将不知道。如果它们只是在它们前面加上“E”，那么您所要做的就是在字符上键入以找到这些特殊的静态类。

【讨论】：

可能与我们不在类前面加上 C 和在结构前面加上 S 的原因相同。对于现代编辑器，修改变量或类型以区分特征只是多余的。

【解决方案6】：

如果以您拥有的方式定义属性，则名称是否相同肯定没有区别。我会说以这种方式使用可能更清楚。

【讨论】：

【解决方案7】：

我推荐 MS 指南。在代码中读取类似“FooEnum”的内容总是很丑陋的编码；）

【讨论】：