Namespaces - How deep is too deep

We are currently reorganising some of our services projects so their naming is more logical. We have the following structure:

Djp.Services.Type. ServiceName

This seems to make sense as a logical grouping, however what I want to know is, is it acceptable to have further levels under this based on the folders in the project. For example one project is called

Djp.Services.Management.Data

Under this project we have a "POCO" folder and a "Repositories" folder, which means, in 开发者_如何学Cprincipal, objects under these folders will have a namespace 5 levels deep.

Is this depth of namespace something that should avoided, or is it perfectly reasonable?

Any namespace that follows the logic of your application structure is fine - regardless of the length.

We have a namespace seven layers deep, with an eighth symbol on the end for the class. The dropdown in the top-left of Visual Studio 2010 that allows you to choose the class within this file doesn't fit our fully qualified class name, and when you mouse over it, there's no tooltip, so the only way to find the class name is to undock the source view and stretch it across two monitors.

I know this is dependent on the total length of the names, and not necessarily the number of nested namespaces, but I'm going to go ahead and define this as "too deep" :)

It can be handy to make your folder structure match your namespace structure, but it makes no sense to make a namespace structure match a folder structure.

The types and members of the namespace(s) are the things you are making. That is the output of your craft and the thing you should be concerned about. The files in the folder are a way to help you do so. You may have already structured the folders such that they match a sensible namespace (essentially you "wrote" the namespace structure when you did so), in which case all and good, but you may also have not done so. The namespaces will matter both to the creators of the assembly(s) and the users of it, the folder structure only to the creators.

Ignore depth, ignore folders, look at the spaces created by the names.

It something smells too long, step back and analyze it. If it passed muster, then I agree completely with @Bozho.

Software development is extremely objective and full of exceptions to hard-fast rules. (couldn't resist)

Tough to answer objectively, but there are a couple things that have given me pause in the past...

• Serialization. When serializing classes, the fully qualified class names often go into some identifier that's included in the serialization. $type in a json file for example. Or on a message bus (e.g. NServiceBus) where they're used with various APIs. For example, I had a FQN of a class that was needed as an even type and the azure service bus API rejected it because it was too long.
• Documentation. Pretty easy to explain this one - run docfx or some other document generator and then look at your table of contents. Have fun with that. Even when using swashbuckle to autogenerate your Swagger/OAS spec files -- you have some FAT object ids.
• In code, when you have two classes with the same name from two different namespaces, they have to be qualified in the code. For example, you could have a bunch that look like this:

Dictionary<MyCompany.Application.Domain.Service.Models.SomeClass, MyCompany.Application.Domain.Service.Models.SomeOtherClass> _someLookup = new Dictionary<MyCompany.Application.Domain.Service.Models.SomeClass, MyCompany.Application.Domain.Service.Models.SomeOtherClass>();

^ that is all one field and it's not even close to the worst I've seen. You can alias them in the directives section to shorten them up in the actual code, but either way, you're gonna have some fat declarations.

I don't know that there's any "wrong" number of levels to go in the naming convention, but there certainly are implications. I'm starting to back away from the approach and something else. For example, I have the Solution named after what it is and have the projects short

• MySolution
  • Project1
  • Project2
  • Etc

It's fairly rare that I run into naming collisions this way, and nine times out of ten, when I run into those situations, it's indicative of a different problem; code-smell really. That's just me. I've also tried to stop nesting directories so deep because those generally become implicit namespaces. You can have namespaces not match the directory structure but that's generally considered bad practice and get really confusing. I've been making my structures flatter and flatter with every new project.

Philosophically, what I would say is to NOT use namespaces as an organization device but rather as a scoping device. The primary difference being that we're engineers and we can organize and re-organize everything under the sun and argue about it all day long, but scoping is more objective. That is, I don't introduce a new scope until I know I need one; when I know I have a collision and renaming the contesting classes is worse that applying scope. "Getting ahead of the problem" in this context can get really messy. Over-engineering?