Framework Design Guidelines Names of Namespaces


Continuing in the series of discussing topics from the Framework Design Guidelines


 


Expert from 3.3 Names of Namespaces


 


DO use a stable, version-independent product name at the second level


of a namespace name.


DO NOT use organizational hierarchies as the basis for names in


namespace hierarchies, because group names within corporations tend


to be short-lived.


BRAD ABRAMS This means staying away from the latest cool and


catchy name the marketing folks come up with. It is fine to tweak the


branding of a product from release to release, but the namespace name is


going to be burned into your client’s code forever. Therefore choose something
that is technically sound and not subject to the marketing whims of the day.


 


I’d love to hear examples of this one… where have you seen a group name or marketing name change that made a namespace name meaningless or worse yet, misleading?

Comments (11)

  1. Rasmus says:

    "Therefore choose something that"

    Something that what?

  2. BradA says:

    Thanks Rastmus… fixed

  3. Shawn Oster says:

    We violated this rule by using a division name in our namespace and when the project grew beyond that division it created a perception that the new divisions weren’t being given equal attention.

    Another thing is make sure people can pronounce your namespace. We used a project name in our namespace and it was named "Intaglio" and it’s pronounced "In + tally + O" but everyone says, "In + TAG + Leo".

  4. While I can’t remark on this specifically regarding namespaces, there was a huge issue with variable naming in our office, where developers would name variables using their initials to differentiate between things. Hence there were oodles of references to "xxRoot", "xxDocument", "xxObject", etc.

    Though one would think it should never need to be said, one should never name variables after oneself.

  5. Jim Wooley says:

    Case of marketing winning out over function:

    ADO.Net

    Why is it still called ADO? No more ActiveX. Actually the only ADO in the ADO namespace is the namespace itself. I guess too many would have been confused by DAL thinking it was a reversion to DAO. DDO (Dotnet Data Objects) could be possible, if it weren’t for DDL. System.NDO could have worked, but it was probably under a NDA…

  6. BradA says:

    Good point Jim… we actually did have this debate which is why we called the namespace "System.Data" rather than "System.ADO.NET"… So we left the marketing name out of the code..

  7. Well, not strictly a namespace issue, but the Mac OS X API known as Cocoa is full of NX prefixes, obviously dating back to the times when the system was called NeXTSTEP…

  8. Well, not strictly a namespace issue, but the Mac OS X API known as Cocoa is full of NX prefixes, obviously dating back to the times when the system was called NeXTSTEP…

  9. Brian says:

    Naming is a common problem for commercial developers. Take for example Partition Magic–still has PQ for many of it’s DLLs and interfaces harkening back to its heritage of PowerQuest. Even Microsoft can’t avoid this issue as their Anti-Spam product has a Giant heritage.

  10. James Kovacs says:

    What about mscorlib.dll? At various times, it stood for Microsoft COM Object Runtime and Microsoft Common Object Runtime, if memory serves me correct. It eventually got branded ".NET", but its heritage as the successor to COM lives on.

    Another confusing area is SharePoint v2.0 development due to renaming concepts between versions. In SPS, you have the notion of SiteCollections and Sites. In the object model, a SiteCollection is represented by SPSite and a Site is a SPWeb, due to the previous version’s programming model and naming. Very confusing for developers getting started with SPS.

  11. Dating says:

    Continuing in the series of discussing topics from the Framework Design Guidelines … Expert from 3.3 Names of Namespaces DO use a stable, version-independent product name at the second level of a namespace name. DO NOT use organizational hierarchies a