Should I worry about reigning in namespace number/length/scope?

Question

I've recently reorganized a solution-in-progress from 24 projects to 4.

To keep the copious files organized in the "main" project, things are in folders in folders in folders. I think I've preserved a logical, discoverable arrangement of the solution content.

As a result, of course, I end up with namespaces like AppName.DataAccess.NHibernate.Fluent.Mappings.

Is there any compelling reason that I should care about flattening out the namespace hierarchy when my project has a somewhat deeply nested folder structure?

(I am not concerned about resolving or managing using directives; I let ReSharper do all the heavy lifting here.)

Answer 1

I have always been of the mind to keep small reusable classes available in meaningful namespace names. So my answer would be NO, don't try to shrink your namespace hierarchy.

Answer 2

I would only flatten where there is a distinct maintenance advantage to do so.

Namespaces are more for organizational purposes with the added benefit of helping to reduce naming conflicts. I tend to keep my namespaces in-line with the .NET Framework and other major library namespaces. This helps others to find classes easier. (As you say, discoverable arrangement.) For instance, my path utilities are under Missico.IO.Path, my data access library under Missico.Data, my application's data access under AppName.DataManager (which uses Missico.Data and all other data namespaces).

I always use my last name or the company's name at the root namespace. (Any noun will do.) This allows the user (programmer) to easily resolve naming conflicts with a simple name change in source code or an using alias for library references.

using Company = Missico;
String x = Company.IO.Path.CommonPath("", "");

I try to keep a folder for each namespace. Nesting the folders if the namespaces are nested. This helps me and others to find source code quicker because they are familiar with the namespace structure. Why make them learn two structures. Each folder contains all the source files for that namespace, except for complex classes. They get there own subfolder (without changing the namespace.) I may end up with a namespace folder that contains four or five subfolders for complex classes and supporting classes.

Note that since defining a System namespace will cause all kinds of trouble, I use Core as my "system/global" namespace.