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.

I would expect to find `MyEnum` in `MyEnum.cs`. Why hide it in another type's file? I can't remember the last time I defined a delegate, as `Action<>` and `Func<>` etc cover those. — David Arno, Jul 05 '17 at 10:37
`Enums` and `Delegates` were only examples, but then you suggest that each and every element of this kind should have _it's own_ cs file? Isn't it an overkill? I can imagine that coming from different sources, this is an easy way, but wouldn't it be more maintainable to store all of these files in a single file? — oneManArmin, Jul 05 '17 at 10:50
I follow what I think is a common convention: put all non-private type definitions (structs, classes, enums and interfaces) in their own files. With most modern IDE's and text editors, its easier to jump between files than it is to scroll up and down a single file that's thousands of lines long. — David Arno, Jul 05 '17 at 11:07
For large-scale projects, this is most certainly true, yes. Thanks for pointing this out! — oneManArmin, Jul 05 '17 at 15:07

score 5 · Accepted Answer · answered Jul 05 '17 at 11:07

5

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 { ... }
}

answered Jul 05 '17 at 11:07

jleach

2,632
9
27

I see, thank you for the suggestion. Previously I though that there is some kind of special way to store them, like in the case of `Interfaces`, but then it's as simple as you write in your first paragraph. – oneManArmin Jul 05 '17 at 15:18
Interfaces are stored the same way... where they belong, in their own file within the folder structure that matches the namespace – jleach Jul 05 '17 at 15:29
Yes, of course. I meant that VS offers the option of adding a new `Interface` item and creates a separate file for it right away. – oneManArmin Jul 05 '17 at 15:37
ah, gotchya... I don't think there's anything similar for enums or delegates. – jleach Jul 05 '17 at 15:42

t3chb0t · Answer 2 · 2017-07-05T13:58:53.190

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.

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

2 Answers2