Should the folders in a solution match the namespace?

Question

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 the MyCompany.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?

Thanks!

Answer 1

Yes they should, only leads to confusion otherwise.

Answer 2

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.

Answer 3

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.

Answer 4

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

Answer 5

@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
    }
}