Amazon.com Widgets

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?

Published 11 November 05 09:52 by BradA

Comments

# Rasmus said on November 12, 2005 8:19 AM:
"Therefore choose something that"

Something that what?
# BradA said on November 12, 2005 12:04 PM:
Thanks Rastmus... fixed
# Shawn Oster said on November 12, 2005 2:59 PM:
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".
# Jason Nussbaum said on November 14, 2005 9:00 AM:
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.
# Jim Wooley said on November 14, 2005 10:38 AM:
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...
# BradA said on November 14, 2005 11:14 AM:
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..
# Pierre Arnaud said on November 17, 2005 6:33 AM:
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...
# Pierre Arnaud said on November 17, 2005 6:34 AM:
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...
# Brian said on November 21, 2005 10:48 AM:
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.
# James Kovacs said on November 28, 2005 12:59 PM:
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.
# Dating said on May 23, 2008 9:03 PM:

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

New Comments to this post are disabled

Search

Go

This Blog

本博客中文版 (View in Chinese)



These postings are provided "AS IS" with no warranties, and confer no rights.

Syndication

Page view tracker