Is it a good idea to keep all the enums in one place?

When I'm building a class library I usually create a file Enums.cs to hold all the enums used in the assembly. Here is an example:

namespace MyNamespace
{
    public enum Colors
    {
        Red,
        Green,
        Blue
    }
    public enum Shapes
    {
        Circle,
        Square,
        Triangle
    }
}

This makes all my enums easy to find, well organized an开发者_如何学Pythond easy to access in code.

I'm wondering if there is any reason why this would not be such a good idea?

It's generally better to arrange definitions by modularity, rather than by kind.

I personally think this is not a good idea. I prefer to keep enums in their own file (one file per defined enum), just like a class. This makes it more obvious (to me) where to go if I'm looking for a type, by name. I treat enums just like a class or struct, or any other namespace-scoped type, which for me means one type per file.

The main downside to your approach arises if you have many Enums defined in your project - that "one file" can get quite large.

However, there is no technical difference in the compiled IL. This really is more of a personal, organizational strategy.

Well, you could apply the same reasoning to all your delegate types, all your classes, all your structs.

By grouping things according to their significance to the compiler, you are losing the opportunity to group them in ways that are meaningful to you. The compiler already knows how to treat them according to their meaning in the language.

Personally when I want to find the declarations relevant to the "Parser" as opposed to the "Configuration Dialog", I go to the place where the code for that feature is kept. I don't have to look in five different places depending on the language features I'm using.

I think it depends on what areas of the code they apply to. If I'm looking at a function in a particular class, I would expect the associated enums to be nearby.

We typically have an entire project, assembly that houses all our Constants, Enums, and helper Methods.

So YES, I would recomend placing them in a central, easily accessable location.

This will allow you to easily access the assembly from other assemblies, trying to avoid circular references.

I go for more of a Namespace organization. Visual Studio makes it too easy to navigate to an object's declaration. It makes more sense to me to have an enum related to database/data access in my MyData namespace rather than some generic enum namespace, i could care less about the file name.

I'm a java developper but i think i can answer here too...

For me it's not a good idea. Like Daniel Earwicker said you could do the same for classes... you could handle your whole application in one single file with many inner classes (i assume in C# like in Java you can have inner classes...), but you don't do it anyway...

And an enum can sometime be a more complex structure, it can have attributes...

A (very) simple exemple in Java:

public enum JobPriority {
    HIGH(5),
    MEDIUM_HIGH(4),
    MEDIUM(3),
    MEDIUM_LOW(2),
    LOW(1)
    ;
    private int level;
    JobPriority(int level) {
        this.level = level;
    }
    public int getLevel() {
        return level;
    }
}

I work on a very big french website and we have enum structures a lot more complex than that... if we had all our enums in one single file this file would make hundreds of lines...

So if your application is small and enum structure is not complex, you can put all of them in one file.

But you'd rather put complex enums in single files on a enum namespace (package in java), and make a enum namespace when needed for each functional part of your application. For simple enums, why not adding then in a common enum file for a given namespace (you can have multiple common enums files). Dunno if it's a good practice.

Does it really matter to you to have many enum files? If you need to find a enum, your IDE perhaps offer you fast class search for finding easily enums no? You can also suffix all your enums by xxxEnum.cs to distinguish them (and also find them all fastly by class name *Enum).

In the java webapp i'm working on (~2 million lines of code, hundreds of enums), we can easily find enums in our Eclipse IDE with shortcuts like ctrl+shift+R + *Enum. It's a lot faster than having common enum files :)

There are certain code-file names that immediately raise a red flag for me. Along with utils.cpp, helpers.vb (or suchlike) if I see an enums.cs I immediately question whether a piece of software is becoming over coupled to enumerations.

Enumerations should be used sparingly and declared near the leaf (least type coupled) types that they are associated with.

Too often I have seen large systems that become over coupled because of shared enumerations. Before too long someone will have the bright idea to enumeration all of the database primary keys.