定位枚举类型的最佳位置在哪里？

I have found that there is generally a singe type or namespace that takes in any particular enum as a parameter and as a result I have always defined those enums there. Recently though, I had a co-worker make a big deal about how that was a stupid thing to do, and you should always have an enum namespace at the root of your project where you define everyone of your enum types.

我发现通常有一个单一的类型或命名空间,它接受任何特定的枚举作为参数,因此我总是在那里定义那些枚举。最近,我有一个同事大肆宣传这是一个愚蠢的事情,你应该总是在项目的根目录中有一个枚举命名空间,你可以在其中定义每个枚举类型。

Where is the best place to locate enum types?

定位枚举类型的最佳位置在哪里?

10 个解决方案

#1

Why treat enums differently to other types? Keep them in the same namespace as they're likely to be used - and assuming they're going to be used by other classes, make them top-level types in their own files.

为什么将枚举与其他类型区别对待?将它们保存在可能被使用的相同名称空间中 - 假设它们将被其他类使用,请将它们作为*类型放在自己的文件中。

The only type of type which I do commonly clump together is delegates - I sometimes have a Delegates.cs file with a bunch of delegates in. Less so with .NET 3.5 and Func/Action, mind you.

我通常聚集在一起的唯一类型是委托 - 我有时会有一个Delegates.cs文件,其中包含一堆委托。对于.NET 3.5和Func / Action,请注意。

#2

Also, namespaces are for separation of things that belong together logically. Not all classes belong in the same namespace just because they are classes. Likewise, not all enums belong in the same namespace just because they are enums. Put them with the code they logically belong in.

此外,命名空间用于逻辑分离属于一起的事物。并非所有类都属于同一名称空间,因为它们是类。同样,并非所有枚举都属于同一名称空间,因为它们是枚举。将它们与逻辑上属于的代码放在一起。

#3

I generally try to put all my different types (classes, interfaces and enums) in their own files, regardless of how small they are. It just makes it much easier to find and manage the file they're in, especially if you don't happen to be in Visual Studio and have the "go to definition" feature available. I've found that nearly every time I've put a "simple" type like that in another class, I end up either adding on to it later on, or reusing it in a way that it no longer makes sense for it to not have its own file.

我通常会尝试将所有不同类型(类,接口和枚举)放在自己的文件中,无论它们有多小。它只是使查找和管理它们所在的文件变得更加容易,特别是如果您不是在Visual Studio中并且具有“转到定义”功能。我发现几乎每次我在另一个类中放置一个“简单”类型的东西时,我最后要么添加它,要么重新使用它以使它不再有意义有自己的文件。

As far as which namespace, it really depends on the design of whatever you're developing. In general, I try to mimic the .NET framework's convention.

至于哪个命名空间,它实际上取决于你正在开发的任何设计。一般来说,我试图模仿.NET框架的约定。

#4

I try to put everything associated with a class in the class. That includes not just enums, but also constants. I don't want to go searching elsewhere for the file or class containing the enums. In a large app with lots of classes and folders, it wouldn't always be obvious where to put the enum file so it would be easy to find.

我尝试将与课程相关的所有内容放在课堂上。这不仅包括枚举,还包括常量。我不想去别处搜索包含枚举的文件或类。在一个包含大量类和文件夹的大型应用程序中,放置枚举文件的位置并不总是很明显,因此很容易找到。

If the enum if used in several closely-related classes, you could create a base class so that the common types like enums are shared there.

如果在几个密切相关的类中使用枚举,则可以创建一个基类,以便在那里共享诸如枚举之类的常见类型。

Of course, if an enum is really generic and widely used, you may want to create a separate class for them, along with other generic utilities.

当然,如果枚举实际上是通用的并且被广泛使用,您可能希望为它们创建一个单独的类以及其他通用实用程序。

#5

I think you put Enums and Constants in the class that consumes them or that uses them to control code decisions the most and you use code completion to find them. That way you don't have to remember where they are, they are associated with the class. So for example if I have a ColoredBox class then I don't have to think about where they are at. They would be part of ColoredBox. ColoredBox.Colors.Red, ColoredBox.Colors.Blue etc. I I think of the enum and constant as a property or description of that class. If it used by multiple classes and no one class reigns supreme then it is appropriate to have an enum class or constants class. This follows rules of encapsulation. Isolating properties from dissimilar classes. What if you decide to change the RGB of Red in Cirle objects but you don't want to change the red for ColoredBox objects? Encapsulating their properties enables this.

我认为你把Enums和Constants放在使用它们的类中,或者使用它们来控制代码决策,并使用代码完成来查找它们。这样你就不必记住它们的位置,它们与课程相关联。因此,例如,如果我有一个ColoredBox类,那么我不必考虑它们的位置。他们将成为ColoredBox的一部分。 ColoredBox.Colors.Red,ColoredBox.Colors.Blue等。我认为枚举和常量是该类的属性或描述。如果它被多个类使用并且没有一个类占主导地位,那么拥有枚举类或常量类是合适的。这遵循封装规则。隔离不同类的属性。如果您决定更改Cirle对象中的红色RGB但又不想更改ColoredBox对象的红色,该怎么办?封装它们的属性可以实现这一点。

#6

What environment?

In .NET I usually create an empty class file, rename it to MyEnum or whatever to indicate it holds my enum and just declare it in there.

在.NET中,我通常创建一个空的类文件,将其重命名为MyEnum或其他任何表明它保存我的枚举并在那里声明它。

#7

If my enumeration has any chance of ever being used outside the class I intend to use it, I create a separate source file for the enum. Otherwise I will place it inside the class I intend to use it.

如果我的枚举有可能在课外使用,我打算使用它,我为枚举创建一个单独的源文件。否则我会将它放在我打算使用它的类中。

#8

Usually I find that the enum is centered around a single class -- as a MyClassOptions type of thing.

通常我发现枚举以单个类为中心 - 作为MyClassOptions类型的东西。

In that case, I place the enum in the same file as MyClass, but inside the namespace but outside the class.

在这种情况下,我将枚举放在与MyClass相同的文件中,但是在命名空间内但在类之外。

namespace mynamespace
{
  public partial class MyClass
  {
  }
  enum MyClassOptions
  {
  }
}

#9

I use nested namespaces for this. I like them better than putting the enum within a class because outside of the class you have to use the full MyClass::MyEnum usage even if MyEnum is not going to * with anything else in scope.

我为此使用嵌套命名空间。我更喜欢它们而不是将枚举放在一个类中,因为在类之外你必须使用完整的MyClass :: MyEnum用法,即使MyEnum不会与范围中的任何其他内容发生冲突。

By using a nested namespace you can use the "using" syntax. Also I will put enums that relate to a given subsystem in their own file so you don't get dependency problems of having to include the world to use them.

通过使用嵌套命名空间,您可以使用“using”语法。此外,我将把与给定子系统相关的枚举放在他们自己的文件中,这样你就不会遇到必须包含世界来使用它们的依赖性问题。

So in the enum header file you get:

所以在enum头文件中你得到:

// MyEnumHeader.h
// Consolidated enum header file for this dll,lib,subsystem whatever.
namespace MyApp
{
  namespace MyEnums
  {
    enum SomeEnum { EnumVal0, EnumVal1, EnumVal2 };
  };
};

And then in the class header file you get:

然后在类头文件中得到:

// MyInterfaceHeader.h
// Class interfaces for the subsystem with all the expected dependencies.

#include "MyEnumHeader.h"

namespace MyApp
{
  class MyInterface
  {
  public:
    virtual void DoSomethingWithEnumParam (MyEnums::SomeEnum enumParam) = 0;
  };
};

Or use as many enum header files as makes sense. I like to keep them separate from the class headers so the enums can be params elsewhere in the system without needing the class headers. Then if you want to use them elsewhere you don't have to have the encapsulating class defs as you would if the enums were declared within the classes.

或者使用尽可能多的枚举头文件。我喜欢将它们与类标题分开,因此枚举可以是系统中其他地方的参数,而不需要类标题。然后,如果你想在其他地方使用它们,你就不必像在类中声明枚举那样使用封装类defs。

And as mentioned before, in the outer code you can use the following:

如前所述,在外部代码中,您可以使用以下内容:

using namespace MyApp::MyEnums;

#10

I tend to define them, where their use is evident in the evident. If I have a typedef for a struct that makes use of it for some reason...

我倾向于定义它们,明显地使用它们。如果我有一个结构的typedef,由于某种原因使用它...

typedef enum {
  HI,
  GOODBYE
} msg_type;

typdef struct {
 msg_type type;
 union {
   int hivar;
   float goodbyevar;
  }
} msg;

#1