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

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 4 years ago.

Improve this 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? O开发者_高级运维r 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.

---

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.

---

This is entirely a matter of style. What I tend to do is to have a file called Enums.cs in the solution in which the enum declarations are collected.

But they are typically found through the F12 key anyway.

---

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.

namespace UserManagement
{
    public enum UserStatus { Active, InActive }
    class User
    {
        ...
    }
}

---

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.

---

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:

enum Result { Success, Error }

---

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.

---

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.

Anything that makes debugging easier, I like.

---

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

---

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.