Avoiding Conflicting Namespace and Class Names in C#

You're right that you shouldn't name the namespace the same as a type it contains. I think there are several approaches you can use:

• Pluralize: Model.DataSources.DataSource

  This works especially well if the primary purpose of the namespace is to contain types that inherit from the same base type or implement the same interface.

• Shorten: Model.QueryStorage

  If a namespace contains only a small number of types, maybe you don't need that namespace at all.

• Make enterprisey: Model.ProjectSystem.Project

  This can work especially for features that are important part of your product, so they deserve their own name.

Two of them are interfaces so I could consider prefixing them with I but I really don't like this convention.

You really should, if your code is used by others (i.e. it's a library) or if you don't want to confuse newcomers to your code.

The easy solution would be one namespace per developer, and I keep track of which names are used. However, I would prefer something more built-to-last.

In what way is your suggested solution not "built-to-last"?

The thing about namespaces is that it is very easy to move things from one namespace to another. Boost does this all the time. The primary definition of something can live in one namespace, while the name exposed to the user comes from a different one.

If you're just experimenting around to find ways to implement things, then each developer should have their own namespace playground. When you want to evaluate a particular experiment, you use the specific namespace they used. When it comes time to integrate one of the variations into the main project, you can use using declarations to bring those symbols into the project namespace.

Indeed, C++11's inline namespace syntax is particularly useful for this, as it can cause one namespace to effectively live within a containing one. This way, the inner namespace still has all of the ADL rules and so forth as if it lived in the outer one.

All of your developers would develop under the root namespace for your project, but they would each have their own sub-namespaces. When it comes time to select which math library (for example) you want to actually use, you simply declare it inline in your primary namespace. This is also good for versioning; you pick the current version to be inlined, while earlier versions can still be made available without the inline keyword.

That's "built-to-last".

Moreover, it is conceivable that we cooperate with other groups of a similar structure, and then we need something global.

And how would a domain name be in any way different from an arbitrary name you pick? Either someone picked a name unilaterally as your root namespace or you all agreed to work under a specific root namespace. Either way, someone had to pick some sequence of characters.

What does it matter if that sequence of characters is a domain name or not? I don't see how inkscape, for example, would be more likely to be selected by a random person by accident than inskcape.org.

Using a domain name as the agreed-upon namespace name will not make it easier to collaborate. So what purpose does it serve to use a domain name as a namespace name?

1) It is very unlikely that someone will use a domain that is not registered to them as namespace.

For a professional project, maybe. For an indie project where the owner is relying on the facilities of GitHub for their stuff? No. Why use a huge domain name like projname.github.io.com for a namespace? The only useful characters in that name are projname; everything else is pointless noise.

Even for a professional project, is cairo really so likely to conflict with someone that cairographics.org is a better alternative? That's 5 useful characters and 12 characters of noise. And sure, IDEs make it easier to write them thanks to tab completion, but that doesn't make it any easier to read.

Names of such length would encourage someone to do namespace projname = projname.github.io.com;, if not flat out using namespace projname.github.io;. So what do you gain?

That's the difference between C++ and Java. If you do import projname.github.io.com.*, that stays in your single .java file. C++ has headers, which don't belong to a single translation unit. And lots of code gets written in headers.

In C++, you are far more likely to have to use a fully-qualified name for a type than in Java.

2) If it happens that someone uses a domain actually registered to us, then it is pretty obvious that they will have to move, not us.

Why do they "have to move" at all? Because it's registered to you? If they got their first, and their project is more popular than yours, who exactly would expect them to change and break lots of people's code?

The point of namespaces is not to guarantee universal distinction between projects. Otherwise, we'd use UUIDs or SHA hashes or something for root namespaces.