Good Namespace Naming Conventions

Question

I am creating a class library for a CRUD business application. The major \"categories\" of business objects (with related data access layer objects) are:

• Maint

Answer 1

After going through this a lot, we try to keep the number of namespaces low (less than a few dozen for a very large project), and the depth of the namespaces short (less than 5 or so). From a consumption standpoint (developers using our codebase), it is an overhead with very little benefit to have to keep track of a large number of namespaces with few classes in them.

We also group like with like, based on usage. If a developer is fairly likely to always use certain classes in conjunction with others, even though (in your example) one may be related to Maintenance and the other not, if they are logically, operationally or procedurally related we put them in the same namespace. The functionality that is separate (for example, maintenance-specific logic) is broken into another namespace using a provider model. Since a developer is less likely to need to modify the provider-contained functionality, that goes in a deeper, separate namespace.

Answer 2

I use one namespace per library and one per executable source code set. The names are always short. For example, in the executable I'm currently working on, I have:

• ALib - my general utility library
• Mongo - my mini web server library
• DBLite - my SQLite3 wrapper & simple persistence layer
• Track1 - executable (actually a couple of executables)

This seems to work pretty well. I find that very complex namespace schemes should be avoided, in the same way that very complex, deep class heirarchies should.

Answer 3

I think the project would benefit from a bit of abbreviation. When I've encountered problems like this in the past, I typically devote a bit of documentation to explaining a few abbreviations that serve as the namespaces. I usually restrict these shortened names to 3-5 characters. Not only does that add to general code readability in the form code, but I've also found that the shorter names lead to less confusion from other coders.

I hope that helps. At the end of the day, it really just depends on your team's preferences...

Answer 4

It seems Ok to me anyway. I would stay away from abbreviations though, that would get confusing and force people to have to know the abbreviations or look them up. Also they become unreadable and unspeakable.

"Lets take a look at the BusObjConfIntContYYYYmmdd package now..."

One issue you might run into is names with subtle differences. With length of names being a possible issue, your eyes might gloss over the whole thing and pick up only part of it. Would there ever be a case where this happened?:

BusinessObjects.Incidents.Classifications
BusinessObjects.Classifications.Incidents

or

BusinessObjects.Forms.ProjectManager.Exportable.Windows.XP
BusinessObjects.Forms.ProductManager.Exportable.Windows.XP

That contrived example might become a problem.

Answer 5

Also have a look at this MSDN article for guidelines for naming Namespaces

Names of Namespaces: http://msdn.microsoft.com/en-us/library/ms229026.aspx

Answer 6

It's generally a good idea to not name your packages after any specific pattern implemented but rather the business or functional domain they belong to.

ie:

Org.MyCompany.BusinessObjects.Maintenance.Contacts
Org.MyCompany.BusinessObjects.Incidents.Contacts
Org.MyCompany.BusinessObjects.Search.Contacts

instead:

Org.MyCompany.Contacts

which would contain classes/interfaces/objects/whatever that perform operations on "Contacts".