The question to ask yourself would be: is there anything about an enumeration type in C# that indicates I should treat it differently from all other types I create?
If the enumeration is public, it should be treated like any other public type. If it is private, declare it as a nested member of the class using it. There is no compelling reason to put two public types in the same file simply because one is an enumeration. The fact that it is a public type is all that matters; the flavor of type does not.
Generally I prefer my enums to be in the same file as the Class that it will most probably be an attribute of. If for example I have a class Task then the enum TaskStatus will be in the same file.
However, if I have enums of a more generic nature, then I keep them contextually in various files.
对于多个类或公共 API 中使用的枚举，我将始终将定义保留在适当命名空间中自己的文件中。找到这种方式要容易得多，并且该策略遵循每个文件一个对象的模式，这也很适合与类和接口一起使用。
It depends on what access is needed.
If the enum is only used by a single class, it's okay to declare it within that class because you don't need to use it anywhere else.
For enums used by multiple classes or in a public API, then I will always keep the definition in its own file in the appropriate namespace. It's far easier to find that way, and the strategy follows the pattern of one-object-per-file, which is good to use with classes and interfaces as well.
I think that depends on the scope of the enum. For example if the enum is specific to one class, for example used to avoid the magic constant scenario, then I would say put it in the same file as the class:
enum SearchType { Forward, Reverse }
If the enum is general and can be used by several classes for different scenarios, then I would be inclined to use put it in its own file. For example the below could be used for several purposes:
我倾向于将枚举放在自己的文件中，原因非常简单：与类和结构一样，如果您想找到类型的定义，最好确切知道在哪里查找：在同名。 （公平地说，在 VS 中您也可以随时使用“转到定义”。）
显然，它可能会失控。我工作的一位同事甚至为代表们制作单独的文件。
I tend to put enums in their own file for a very simple reason: as with classes and structs, it's nice to know exactly where to look if you want to find a type's definition: in the file of the same name. (To be fair, in VS you can always use "Go to Definition," too.)
Obviously, it can get out of hand. A colleague where I work even makes separate files for delegates.
If you are using the USysWare File Browser add-in for Visual Studio, you can very quickly find files of particular names in your solution. Imagine looking for an enum that is not in its own file but instead buried in some file in a gigantic solution.
For small solutions, it doesn't matter, but for large ones, it becomes all the more important to keep classes and enums in their own files. You can quickly find them, edit them, and more. I highly, highly recommend putting your enum in its own file.
And as was stated... How wasteful is a file that ends up only being a couple of kb anyways?
Very simple huge advantage to separate file. When any object is in its own MyObjectName.cs file... you can go to solution explorer and type MyObjectName.cs and be shown exactly 1 file. Anything that makes debugging better is nice.
Another advantage on a similar note, if you search all files (ctrl+shft+F) for a name, you may find 20 references to the name in the same file... and that found name will be part of different objects. In the Find Results window all you can see is the line number and the file name. You would have to open the file and scroll to figure out which object the found reference was in.
If you have multiple projects in one solution. Then better create another project Utilities. Then create a Folder \Enumerations and create a nested static class. And then assign each static class where you will create enum that corresponds to the name of your projects. For example you have a project named DatabaseReader and DatabaseUsers then you may name the static class like
public static class EnumUtility {
#region --Database Readers Enum
public static class EnumDBReader {
public enum Actions { Create, Retrieve, Update, Delete};
}
#endregion
#region --Database Users Enum
public static class EnumDBUsers {
public enum UserIdentity { user, admin };
}
#endregion
}
Then entire enum that can be used in the entire solutions per projects will be declared on it. Use #region to separate each concern. By this, it is easier to look for any enums
我喜欢有一个名为 E 的公共枚举文件，其中包含每个单独的枚举，然后可以使用 E 访问任何枚举...并且它们位于一个位置进行管理。
I like to have one public enums file named E containing each seperate enum, then any enum can be accessed with E... and they are in one place to manage.
I wouldn't say "wasteful" (how much does an extra file cost?), but it is often inconventient. Usually there's one class that's most closely associtated with the enum, and I put them in the same file.
I prefer to put each enumeration in its own file (likewise for each interface, class, and struct, no matter how small). It makes them easier to find when I'm coming from another solution or otherwise don't already have a reference to the type in question.
Putting a single type in each file also makes it easier to identify changes in source control systems without diffing.
发布评论
评论（15）
这完全是风格问题。我倾向于做的是在收集枚举声明的解决方案中创建一个名为
Enums.cs的文件。但无论如何，它们通常都是通过 F12 键找到的。
This is entirely a matter of style. What I tend to do is to have a file called
Enums.csin the solution in which the enum declarations are collected.But they are typically found through the F12 key anyway.
要问自己的问题是：C# 中的枚举类型是否有任何内容表明我应该以不同于我创建的所有其他类型的方式对待它？
如果枚举是公共的，则应像对待任何其他公共类型一样对待它。如果它是私有的，请将其声明为使用它的类的嵌套成员。没有令人信服的理由将两种公共类型放在同一个文件中，仅仅因为其中一种是枚举。重要的是它是一个公共类型。类型的味道没有。
The question to ask yourself would be: is there anything about an enumeration type in C# that indicates I should treat it differently from all other types I create?
If the enumeration is public, it should be treated like any other public type. If it is private, declare it as a nested member of the class using it. There is no compelling reason to put two public types in the same file simply because one is an enumeration. The fact that it is a public type is all that matters; the flavor of type does not.
将每种类型（类、结构、枚举）放在自己的文件中的另一个优点是源代码控制。您可以轻松获取该类型的整个历史记录。
Another advantage of putting each type (class, struct, enum) in its own file is source control. You can easily get the entire history of the type.
我主要放置在命名空间内部和类外部，以便可以轻松访问该命名空间中的其他类，如下所示。
I place mostly inside in namespace and outside of class so that it is easily accessible other classes in that namespace like below.
一般来说，我更喜欢我的枚举与它很可能是其属性的类位于同一个文件中。例如，如果我有一个类
Task，那么枚举TaskStatus将位于同一个文件中。但是，如果我有更通用的枚举，那么我会将它们根据上下文保存在各个文件中。
Generally I prefer my enums to be in the same file as the Class that it will most probably be an attribute of. If for example I have a class
Taskthen the enumTaskStatuswill be in the same file.However, if I have enums of a more generic nature, then I keep them contextually in various files.
这取决于需要什么访问权限。
如果枚举仅由单个类使用，则可以在该类中声明它，因为您不需要在其他任何地方使用它。
对于多个类或公共 API 中使用的枚举，我将始终将定义保留在适当命名空间中自己的文件中。找到这种方式要容易得多，并且该策略遵循每个文件一个对象的模式，这也很适合与类和接口一起使用。
It depends on what access is needed.
If the enum is only used by a single class, it's okay to declare it within that class because you don't need to use it anywhere else.
For enums used by multiple classes or in a public API, then I will always keep the definition in its own file in the appropriate namespace. It's far easier to find that way, and the strategy follows the pattern of one-object-per-file, which is good to use with classes and interfaces as well.
我认为这取决于枚举的范围。例如，如果枚举特定于一个类，例如用于避免魔术常量场景，那么我会说将其与该类放在同一个文件中：
如果枚举是通用的并且可以由多个类用于不同的场景，那么我会倾向于使用将其放入自己的文件中。例如，以下内容可用于多种目的：
I think that depends on the scope of the enum. For example if the enum is specific to one class, for example used to avoid the magic constant scenario, then I would say put it in the same file as the class:
If the enum is general and can be used by several classes for different scenarios, then I would be inclined to use put it in its own file. For example the below could be used for several purposes:
我倾向于将枚举放在自己的文件中，原因非常简单：与类和结构一样，如果您想找到类型的定义，最好确切知道在哪里查找：在同名。 （公平地说，在 VS 中您也可以随时使用“转到定义”。）
显然，它可能会失控。我工作的一位同事甚至为代表们制作单独的文件。
I tend to put enums in their own file for a very simple reason: as with classes and structs, it's nice to know exactly where to look if you want to find a type's definition: in the file of the same name. (To be fair, in VS you can always use "Go to Definition," too.)
Obviously, it can get out of hand. A colleague where I work even makes separate files for delegates.
使用单独的枚举文件的优点之一是您可以删除使用该枚举的原始类并使用该枚举编写一个新类。
如果枚举独立于原始类，那么将其放在单独的文件中将使将来的更改更容易。
One advantage of using a separate file for enums is that you can delete the original class that used the enum and write a new class using the enum.
If the enum is independent of the original class then putting it in a separate file makes future changes easier.
如果您使用 Visual Studio 的 USysWare 文件浏览器插件，您可以非常快速地在解决方案中找到特定名称的文件。想象一下寻找一个不在其自己的文件中而是埋藏在巨大解决方案中的某个文件中的枚举。
对于小型解决方案，这并不重要，但对于大型解决方案，将类和枚举保留在自己的文件中变得更加重要。您可以快速找到它们、编辑它们等等。我强烈建议将您的枚举放在自己的文件中。
正如前面所说...一个最终只有几 kb 的文件有多浪费？
If you are using the USysWare File Browser add-in for Visual Studio, you can very quickly find files of particular names in your solution. Imagine looking for an enum that is not in its own file but instead buried in some file in a gigantic solution.
For small solutions, it doesn't matter, but for large ones, it becomes all the more important to keep classes and enums in their own files. You can quickly find them, edit them, and more. I highly, highly recommend putting your enum in its own file.
And as was stated... How wasteful is a file that ends up only being a couple of kb anyways?
分离文件非常简单，有巨大的优势。当任何对象位于其自己的 MyObjectName.cs 文件中时...您可以转到解决方案资源管理器并键入 MyObjectName.cs 并仅显示 1 个文件。任何能让调试变得更好的东西都是好的。
类似说明的另一个优点是，如果您搜索所有文件 (ctrl+shft+F) 的名称，您可能会找到 20 个引用同一文件中的名称...并且找到的名称将是不同对象的一部分。在“查找结果”窗口中，您只能看到行号和文件名。您必须打开文件并滚动以找出找到的引用所在的对象。
我喜欢任何使调试更容易的东西。
Very simple huge advantage to separate file. When any object is in its own MyObjectName.cs file... you can go to solution explorer and type MyObjectName.cs and be shown exactly 1 file. Anything that makes debugging better is nice.
Another advantage on a similar note, if you search all files (ctrl+shft+F) for a name, you may find 20 references to the name in the same file... and that found name will be part of different objects. In the Find Results window all you can see is the line number and the file name. You would have to open the file and scroll to figure out which object the found reference was in.
Anything that makes debugging easier, I like.
如果您在一个解决方案中有多个项目。然后最好创建另一个项目
Utilities。然后创建一个文件夹\Enumerations并创建一个嵌套的静态类。然后分配每个静态类，您将在其中创建与项目名称相对应的枚举。例如，您有一个名为 DatabaseReader 和 DatabaseUsers 的项目，那么您可以将静态类命名为“然后可以在每个项目的整个解决方案中使用的整个枚举”将在其上声明。使用#
region来分隔每个关注点。这样，查找任何枚举就更容易了If you have multiple projects in one solution. Then better create another project
Utilities. Then create a Folder\Enumerationsand create a nestedstatic class. And then assign each static class where you will create enum that corresponds to the name of your projects. For example you have a project named DatabaseReader and DatabaseUsers then you may name the static class likeThen entire enum that can be used in the entire solutions per projects will be declared on it. Use #
regionto separate each concern. By this, it is easier to look for any enums我喜欢有一个名为 E 的公共枚举文件，其中包含每个单独的枚举，然后可以使用 E 访问任何枚举...并且它们位于一个位置进行管理。
I like to have one public enums file named E containing each seperate enum, then any enum can be accessed with E... and they are in one place to manage.
我不会说“浪费”（额外的文件要花多少钱？），但它通常很不方便。通常有一个类与枚举关系最密切，我将它们放在同一个文件中。
I wouldn't say "wasteful" (how much does an extra file cost?), but it is often inconventient. Usually there's one class that's most closely associtated with the enum, and I put them in the same file.
这实际上只是一个偏好问题。
我更喜欢将每个枚举放在自己的文件中（每个接口、类和结构也是如此，无论多小）。当我来自另一个解决方案或者还没有对相关类型的引用时，它使它们更容易找到。
在每个文件中放入单一类型还可以更轻松地识别源代码控制系统中的更改，而无需进行比较。
This is really just a matter of preference.
I prefer to put each enumeration in its own file (likewise for each interface, class, and struct, no matter how small). It makes them easier to find when I'm coming from another solution or otherwise don't already have a reference to the type in question.
Putting a single type in each file also makes it easier to identify changes in source control systems without diffing.