Should enums in C# have their own file? [closed]

Question

I have a class which uses an enumeration, the enum is currently in its own file which seems wasteful.

What is the general opinion on enums being placed within the namespace of a file that they are consumed in? Or should the enum really live in its own cs file?

Edit

I should mention that while the class in question uses these enumerations, so does external callers. In other words, another class can set these enumerations. So they are not used internally to the class, otherwise this question would be a no brainer.

Answer 1

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

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.