What should I know when choosing a namespace name?

I'm tasked with choosing a name that will in effect be the internal name of our architecture. I'm taking this responsibility seriously, as I have worked with a lot of "bad" namespaces and don't want to inflict one on others.

What makes a "bad" namespace to me?

In terms of human factors:

An acronym that is essentially meaningless: DDL, MOS, etc
A namespace that collides with a common one from another vendor, like Office or Text or IO
A namespace that's difficult to spell or pronounce for non-native English speakers because it's either a foreign word or a proper noun: Vancouver

and so on.

I feel comfortable choosing a namespace in terms of descriptive ability and mnemonic. I'm wondering what the technical consequences of namespace names can be. For instance, what problems might arise from the namespace _, which is a legal C# namespace name? What about a single letter, like e? Are there namespaces that give CodeDom or Reflector fits? Do some namespaces that are legal in C# cause problems in other .Net languages? Is it possible to choose a namespace that is not Mono-compliant for some reason? Have you worked with a namespace that made your life difficult for reasons involving the compiler or Visual Studio or the Windows (or Linux) filesystem?

Thanks for reading and thanks in advance for any help!

Solution

For non-technical stuff, read the Frameworks Design Guidelines. They have lots of good advice. Briefly:

Start with a company name.
choose stable (version-independent) names. FrobCorp.FrobozzleV2.Utilities is bad.
choose names that reflect the code purpose rather than the politics of the organization that produced it. FrobCorp.AdvancedResearchDivision.CambridgeOffice is bad; the AdvancedResearchDivision might be renamed tomorrow and the Cambridge office might be relocated.
use PascalCase unless that violates your branding. FrobCorp.jFrobozzle looks terrible, but FrobCorp.Jfrobozzle looks even worse.
use plurals when appropriate
and so on.

There is a lot more good advice in the guidelines that I have not reproduced here. Go read them.

However, it sounds like you've got the non-technical stuff down. One of the bits of advice in the guidelines is "do not name a type the same as its namespace". That is good advice not just because doing so is confusing to readers; there is a good technical reason as well.

For the technical reasons why naming a type the same as its namespace is a terrible idea, see my articles on the subject:

https://web.archive.org/web/20120111133911/http://blogs.msdn.com/b/ericlippert/archive/2010/03/09/do-not-name-a-class-the-same-as-its-namespace-part-one.aspx (At least as of January 2020, this is only available on archive.org.)