在确定应该定义枚举和结构的位置时，有什么好的做法？

Question

假设enum或struct未嵌套在特定类中，即它属于项目命名空间，是否应在以下位置定义：

• 自己的文件
• 名为Enums.cs或Structs.cs的通用文件，其中将定义属于项目命名空间的所有enums / structs
• 其他地方......

Answer 1

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

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

Answer 2

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

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

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

Answer 3

This MSDN article on enum best practices不建议存储枚举定义的位置。

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

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

Answer 4

我把所有的枚举都放在自己的文件中。但是，我也完全xml doccomment我的所有类型，包括枚举......所以我的枚举文件中可能有比许多人更多的代码行。

我在很多年里都没有写过一个结构，但是我不认为它们不是一个类（而且我的所有类型，包括结构都是完整的xml doccomment），所以他们有在过去总是有自己的文件。

当涉及到代表时，因为它们通常是一个衬里（减去doccomment），我倾向于将它们保存在与它们支持的任何更突出的类型相同的文件中。这些天我不经常写代表，但有时我发现他们仍然有用。但是，我尝试将任何委托声明放在文件的顶部，而不是嵌套在主要类型之下......当你去寻找它们时，更容易发现它们。

我认为将每种类型保存在自己的文件中也有一个非常简单但实际的原因。他们非常容易发现这种方式。如果你将你的枚举和结构埋在其他类型中，或者将它们保存在另一个文件中，有时候（并且不要假设你，阅读代码的人，总是可以访问Visual Studio及其所有丰富的工具）它可以是很难找到你想要的类型。