Should the folders in a solution match the namespace?

Viewed 56509

Should the folders in a solution match the namespace?

In one of my teams projects, we have a class library that has many sub-folders in the project.

Project Name and Namespace: MyCompany.Project.Section.

Within this project, there are several folders that match the namespace section:

  • Folder Vehicles has classes in the MyCompany.Project.Section.Vehicles namespace
  • Folder Clothing has classes in theMyCompany.Project.Section.Clothing namespace
  • etc.

Inside this same project, is another rogue folder

  • Folder BusinessObjects has classes in the MyCompany.Project.Section namespace

There are a few cases like this where folders are made for "organizational convenience".

My question is: What's the standard? In class libraries do the folders usually match the namespace structure or is it a mixed bag?

7 Answers

Also, note that if you use the built-in templates to add classes to a folder, it will by default be put in a namespace that reflects the folder hierarchy.

The classes will be easier to find and that alone should be reasons good enough.

The rules we follow are:

  • Project/assembly name is the same as the root namespace, except for the .dll ending
  • Only exception to the above rule is a project with a .Core ending, the .Core is stripped off
  • Folders equals namespaces
  • One type per file (class, struct, enum, delegate, etc.) makes it easy to find the right file

I think the standard, within .NET, is to try to do it when possible, but not to create unnecessarily deep structures just to adhere to it as a hard rule. None of my projects follow the namespace == structure rule 100% of the time, sometimes its just cleaner/better to break out from such rules.

In Java you don't have a choice. I'd call that a classic case of what works in theory vs what works in practice.

@lassevk: I agree with these rules, and have one more to add.

When I have nested classes, I still split them out, one per file. Like this:

// ----- Foo.cs
partial class Foo
{
    // Foo implementation here
}

and

// ----- Foo.Bar.cs
partial class Foo
{
    class Bar
    {
        // Foo.Bar implementation here
    }
}

I'd say yes.

First, it will be easier to find the actual code files by following down the namespaces (say, when somebody e-mails you a naked exception call stack). If you let your folders go out of sync with namespaces, finding files in big codebases becomes getting tiring.

Second, VS will generate new classes you create in folders with the same namespace of its parent folder structure. If you decide to swim against this, it will be just one more plumbing job to do daily when adding new files.

Of course, this goes without saying that one should be conservative about how deep xis folder/namespace hierarchy goes.

Yes they should, only leads to confusion otherwise.

What's the standard?

There is no official standard but conventionally the folder-to-namespace mapping pattern is most widely used.

In class libraries do the folders usually match the namespace structure or is it a mixed bag?

Yes, in most class libraries the folders match the namespace for organizational ease.

Related