.NET: How do you decide how to structure your Namespaces?

Question

I'm wondering what guidelines you guys are using for determining the structure for your Namespaces. When do you decide something warrants it's own Namespace?

I read in a forum discussion or article that a best practice is to go for a shallow tree with as few child Namespaces as possible but can't remember the reasoning behind it or the link.

Now I'm just doing what 'feels right' but would prefer some more concrete guidelines especially to explain to newer developers.

Thanks.

Answer 1

Microsoft has guidelines on namespace naming, here too.. Brad Abrams has his thoughts.

Answer 2

I go for the shallow tree approach, myself. One of the negative consequences of many-layered namespaces is the proliferation of same-named and same-functioned classes within a single project (differentiated only by their different namespace locations), or even worse: same-named and differently-functioned classes in the same project. Having only a single namespace in a project forces developers to give each separate class a good, self-descriptive name.

Having multiple folders in a project is still a good idea, however (for organizational purposes), and I wish there was an option in Visual Studio such that classes added inside a sub-folder can not automatically have the folder names added to their namespaces (there may be such an option in the versions newer than 2005). I work around this by always adding new classes at the root level and then dragging them into their appropriate folders.

Answer 3

I use multiple folders (multi-level-folders) in the solution and some times in projects.

I map solution folders to namespaces, occasionaly giving projects a sub-namespace.

Most my projects have one namespace.

E.g.

Company.Product.Initialization // (exe project)
Company.Product.Data.Interfaces // interfaces (dll)
Company.Product.Data.Collections // collections (dll)
Company.Product.Data.Binding // binding logic (dll)
Company.Product.Data.Binding.Tests // unit tests for above (dll)
Company.Product.Data.Serialization
Company.Product.Data.Serialization.Tests
Company.Product.Model // (dlls)
Company.Product.Gui.Controls // (dlls)
Company.Product.Gui.Windows // (dlls)
Company.Product.Gui.ModelView // (dlls)
Company.Product.Gui.Logic // (dlls)

I agree with MusiGenesis about the importance of good names and also suggest reading MS's guidelines (preferably for C# 3.5 or 4.0 though).