Jon Galloway

good luck with that...

I'm not expecting everyone to follow it, but I'd bet if there was a general best practices recommendation out there then a lot of people would use it. Whenever I post code, I waste time trying to decide what the namespace should be. I'd prefer if someone else waste that time once and for all.

+1 for Community.[ProjectName]

I agree. I like the idea of [Organisation].[ProjectName]... or [Organisation].[ProductName]... If there was a sensible recommendation I'd probably follow it and encourage others to do so.

I have a modest proposal for you: how about NO F'ING NAMESPACE! They're little more than vanity plates for your code.

For example, I built this class MhtBuilder. It lets you duplicate the "Save as single file" functionality in IE using 100% managed code, and I posted it on CodeProject. It's not going to cure cancer or anything, but it's useful, not that common, and worth sharing. Do I really NEED to call this class..

JeffAtwoodIsSoCool.MhtBuilder
AwesomeAtwoodWare.MhtBuilder
AtwoodHeavyIndustries.MhtBuilder

C'mon. Let's stop kidding ourselves here. How many namespace collisions are we going to have, where you just happen to have a class called MhtBuilder in your project?

If you're distributing *signed binaries with no source*, then you can arguably make a case that you need a namespace. Otherwise, stop with the veiled ego tripping, call your class what it does, and have the cojones to leave it at that.

That's an interesting spin Jeff. For me I'm not so worried about collisions. More about using a standard way to keep my stuff organised. And a standard would mean I don't need to think about it when creating a namespace. Often I have classes called the same (and it makes sense it these situations), so I definetly need to use namespaces.

At work I use CompanyAbbreviation.Something where Something is specific to the code. If its library code, I'll try to use something similar to the System namespace. For example, my socket server class is:

Company.Net.Sockets.SocketServerBase

Haacked Phil -
I think that's evolving into a standard for corporate code. What about for general community code, though?

I think Megacorp.Net.SocketServerBase is becoming general practice for corporate code, and Socketworks.Net.SocketServerBase is expected if the code is part of a Socketworks project / product, but if I post code for a Socket Server Base, what would you expect the namespace to be?

So if I'm writing a freeware WinForms application, do you think I should code its classes as being in a "Community.<ApplicationName>" namespace (and subnamespaces therein)?

Or is this something you'd really only worry about with components and/or class libraries?

I'm mostly just concerned with components, class libraries, and classes which are shared as code. I can see going with the Community.* namespaces if people will use the code later.

Jon Galloway recently pointed out something that's been bothering me for a while: I'm happy to see the huge growth of community contributed code - things like RSS.NET, sharpziplib, ftp classes to tide us over 'til .NET 2.0, etc....

do you think its that bad:

NAnt:
Nant.Core.dll ( NAnt.Core namespace )
NANt.DotNetTasks ( NAnt.DotNetTasks nspace )

NDoc:
NDoc.Core.dll ( NDoc.Core namespace )

amd others like NUnit seem similarly well organised.
Naming the asembly after the namespace is a pretty good practice generally - and is whats ( mostly ) used by the framework libraries.

Ian -
I agree with everything you've said - namespace root is the name of the project, assembly name matches namespace.

I'm not concerned with the namespaces used in projects. Some industry standards would be good there, too, but I don't see them as a problem.

I'm more concerned with one off utility classes, tiny utility DLL's, freeware server controls, etc.