Is there an Ideal way of storing namespace-related elements?

Question

In the title, with namespace-related elements, I refer to Enums, Delegates and other elements that do not belong to a single class, but to the whole namespace, or application. I know that I can cram these into the namespace just about anywhere, for example, if I use WPF, I usually put them into App.xaml.cs, so that I always know where to find all of them:

namespace MyNameSpace
{

    enum MyEnum
    {
       element1, element2
    };

    public delegate void MyDelegate();

    public partial class App : Application
    {
        /*some App-wide code here*/
    }
}

I would like to know, however, if there is a generally accepted way of doing this that developers are expected to know about and use like in the form of a Design Pattern or Best Practises, so that I can get used to this early on. I would also be glad to read about not exactly general, but practical ways with (brief) explanation (e.g., uses less resources than another way, or it is easier to UnitTest it etc.) as to why is that particular way of arranging these items is good.

Answer 1

Why not its own file within the namespace it belongs?

For example, if I'm working on Legal Matters in my Domain project and I have an enum of MatterStatus, I'd place the enum with a MatterStatus.cs file in the Domain.Legal.Matters namespace.

Not only does this put the file(s) where I'd expect them to be, but when I need to actually use that enum in code, it's a reasonable namespace for me to do so.

I'd be wary of storing business-level enums in an application-level project (such as WPF). What if you need to use some other frontend utility? You won't be able to re-use that enum unless you have it in a project that both WPF and said utility can reference (e.g., a Domain or Business Layer)

Once in a while, if it's a very simple model, I'll include the enum directly within the main class's file:

namespace MyProject.Domain.Legal.Matters
{
    public enum MatterStatus {
        Open,
        Closed
    }

    public class Matter { ... }
}

Answer 2

Besides good practices mentioned by @jdl134679 there are also bad practices that you should avoid: for example you should not create namespaces like Enums or Delegates that do not have any practical value. If you want to group your enums (or anything else) together then you can create a new folder for them (I sometimes do it for similar items) but remember to remove its name from the namespace if you create a new file or if you are using ReSharper to tell it that this folder is not a namespace provider (you can set it in the properties).

Another namespace that is often abused is the Common namespace. You should have a really good reason for it and not to use it to dump everything there that doesn't seem to fit anywhere else yet.

As far as separate files and delegates are concerned I treat them exceptionally and usually put them in the same file that requries them.

If you are not sure how to organize your files and need some inspiration I suggest taking a look at View > Object Explorer and see how .Net is organized.