[wish] Community code namespace standards

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.

One thing that bothers me about it is the namespaces. The .NET System namespaces are beautifully organized, but community / open source code namespaces are an anarchistic babel. Those that originate from a big company usually start with the company name, those that come from larger project usually take the the project's name.

One-off code snips / hobbyist / micro-projects usually contain a random concatenation of some or all of the following words: monkey, alien, squishy, bug, fuzzy, code, util, works, MyNamespace, namespace, ware, example, contrib, and lib: monkeyCode, fuzzyAlienWare, utilLib, bugware, etc. This is the case I'm talking about.

I can sort of see the point of company based or project based namespaces. I don't see any value in random namespace names, though. They don't tell anyone anything, and they look suspect to managers and system admins - "What's this bugworksLib.dll?"

I understand there may be concern about twenty different Community.Network.Ftp namespaces floating around, but .NET is smart enough to figure it out, or at least warn you at compile time.

I'd like to see a community standard best practice for community code namespaces - anything remotely professional would do: Community, Shared, Code, etc.


powered by IMHO


  • 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..




    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.

  • 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.

  • do you think its that bad:


    Nant.Core.dll ( NAnt.Core namespace )

    NANt.DotNetTasks ( NAnt.DotNetTasks nspace )


    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.

Comments have been disabled for this content.