Where is the best place to locate enum types?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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 enum {
  HI,
  GOODBYE
} msg_type;

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

Answer 5

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

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

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

Answer 6

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.

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.