决定枚举和结构体定义位置的良好实践是什么？

Question

3

假设enum或struct不嵌套在特定类中，即它属于项目命名空间，应该定义在哪里？

- jpoh

4个回答

6

对我而言，一个类型等于一个文件，除非它是委托。由于 Func 和 Action，我现在很少需要声明自己的委托，但当我这样做时，我发现有一个 Delegates.cs 文件很有用。

至于结构体 - 除了为测试可变结构体可能会出现的问题之外，我只记得写过两个结构体。但我也会坚持每个文件只有一个结构体。你为什么不这样做呢？仅仅因为它们是值类型并不意味着它们比类更短或更简单。(你能想象如果 decimal 和 DateTime 在同一个源文件中吗？哎呀！)

编辑：我刚想到另一种情况，可能适合使用多个结构体：互操作。在这种情况下，我可能会有 Interop.cs 或 Win32.cs... 或者可能为其创建一个命名空间，并恢复每个类型一个文件的方式。

- Jon Skeet

5

这篇MSDN枚举最佳实践文章没有建议枚举定义应该存储在哪里。

不同的人会有不同的建议。个人倾向于将枚举与相关类存储在同一个文件中。我喜欢保持文件结构与命名空间结构尽可能相同，因此如果我的枚举自然地属于特定的命名空间，我将在相应的文件中存储定义。

我的建议是找到适合您的方案，并坚持使用它。

- Michael Petrotta

2

我把所有的枚举都放在它们自己的文件中。然而，我也完全地用xml文档注释了我所有的类型，包括枚举...所以我的枚举文件里可能有比大多数人更多的代码行。

很多年来，我没有写过结构体，但我不认为它们比类差（并且再次，我完全用xml文档注释了我所有的类型，包括结构体），因此它们过去总是有它们自己的文件。

当涉及到委托时，它们通常只有一行（减去文档注释），所以我倾向于将它们与支持它们的更主要的类型放在同一个文件中。我现在不经常写委托，但有时候我发现它们仍然有用。然而，我尽量将任何声明的委托放在文件顶部，而不是嵌套或放在主类型下面...这样更容易找到它们。

我认为保持每个类型在它自己的文件中也有一个非常简单但实用的原因。这样很容易找到它们。如果你把你的枚举和结构体埋在其他类型中，或者把它们放在另一个文件中，有时候（不要假设你和阅读你代码的人总是有Visual Studio和它丰富的工具）找到你想要的类型可能会很困难。

- jrista

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- JaredPar · Accepted Answer

个人而言，我更喜欢一种类型一个文件的理念。我甚至会将嵌套类型放在单独的文件中，并使用部分类来实现分离。

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