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.

  • 1
    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
    Commented Jul 5, 2017 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? Commented Jul 5, 2017 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
    Commented Jul 5, 2017 at 11:07
  • For large-scale projects, this is most certainly true, yes. Thanks for pointing this out! Commented Jul 5, 2017 at 15:07

2 Answers 2


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 {

    public class Matter { ... }
  • 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. Commented Jul 5, 2017 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
    Commented Jul 5, 2017 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. Commented Jul 5, 2017 at 15:37
  • ah, gotchya... I don't think there's anything similar for enums or delegates.
    – jleach
    Commented Jul 5, 2017 at 15:42

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.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.