在决定应该在哪里定义枚举和结构时，什么是好的做法？

Question

假设enum或struct没有嵌套在一个特定的类，即它属于项目命名空间内，它应该在被定义为：

• 它自己的文件
• 通用文件名为Enums.cs或Structs.cs在所有的enums/structs属于该项目命名空间将被定义
• 别的地方...

Answer 1

This MSDN article on enum best practices不建议在哪里存储枚举定义。

你会得到不同的建议。就我个人而言，我倾向于将枚举存储在与其相关的类相同的文件中。我希望尽可能使我的文件结构与我的命名空间结构保持一致，因此如果我的枚举自然落入特定的命名空间，我会将该定义存储在相应的文件中。

我的建议是，找一个适合你的方案，并坚持下去。

Answer 2

个人而言，我更喜欢一种类型，一种文件哲学。我甚至在嵌套类型的单独文件中使用了部分类来允许分离。

我主要这样做是因为我看到了太多相反的东西。包含数十个类的单个文件。经历改变了我。

Answer 3

对我来说，一种类型=一个文件，除非它是一个委托。由于Func和Action，我现在不需要经常声明自己的代表，但是当我这样做时，我发现有一个Delegates.cs文件是有用的。

至于结构 - 我只能记得写关于其中两个，除了为了测试结构可以做的mutable这些坏事情。但我也会坚持每个文件一个。你为什么不呢？仅仅因为它们是值类型并不意味着它们自然比类更短或更简单。 （你能想象如果decimal和DateTime都在同一个源文件？Eek！）

编辑：我刚刚想过另一种情况，其中有多个结构可能是适当的：互操作。在这种情况下，我可能会有Interop.cs或Win32.cs ...或者可能有一个命名空间，并返回到每种类型的一个文件。

Answer 4

我把我所有的枚举放在他们自己的文件中。但是，我也完全xml doccomment所有我的类型，包括枚举...所以我的枚举文件中可能有更多的代码行比大多数人。我没有写很多年的结构，但我不认为它们比任何一个类都少（再次，我完全xml doccomment包括我的所有类型，结构），所以他们在过去总是有自己的文件。

当涉及到代表，因为它们通常是一个衬垫（减去doccomment），所以我倾向于将它们保留在相同的文件中，而不管它们支持哪种更突出的类型。这些天我不经常写代表，但有时我发现他们仍然有用。不过，我会尽量让任何代表在文件顶部声明，而不是嵌套或低于主类型......让他们更容易找到它们。

我认为还有一个非常简单但实际的理由，让每个类型都保存在自己的文件中。他们很容易找到这种方式。如果您将枚举和结构埋入其他类型中，或将它们保存在另一个文件中，有时（并不假设您，以及读取您的代码的人员始终访问Visual Studio及其所有丰富的工具），它可以是很难找到你想要的类型。