Names of Namespaces

Article
11/03/2006

The name chosen for a namespace should indicate the functionality made available by types in the namespace. For example, the System.Net.Sockets namespace contains types that enable developers to use sockets to communicate over networks.

The general format for a namespace name is as follows:

<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]

For example, Microsoft.WindowsMobile.DirectX.

Do prefix namespace names with a company name to prevent namespaces from different companies from having the same name and prefix.

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.

The namespace name is a long-lived and unchanging identifier. As organizations evolve, changes should not make the namespace name obsolete.

Do use Pascal casing, and separate namespace components with periods (for example, Microsoft.Office.PowerPoint). If your brand employs nontraditional casing, you should follow the casing defined by your brand, even if it deviates from normal namespace casing.

Consider using plural namespace names where appropriate. For example, use System.Collections instead of System.Collection. Brand names and acronyms are exceptions to this rule, however. For example, use System.IO instead of System.IOs.

Do not use the same name for a namespace and a type in that namespace. For example, do not use Debug for a namespace name and also provide a class named Debug in the same namespace. Several compilers require such types to be fully qualified.

Namespaces and Type Name Conflicts

If you choose a namespace or type name that conflicts with an existing name, library users will have to qualify references to the affected items. This should not be the case in most development scenarios.

Some of the guidelines presented in this section are relevant to the following categories of namespaces:

Application model namespaces
Infrastructure namespaces
Core namespaces
Technology namespace groups

The namespaces in an application model provide the set of functionality specific to a class of applications. For example, the types in the System.Windows.Forms namespaces provide the functionality required to write Windows forms client applications. The types in the System.Web namespaces support writing Web-based server applications. In general, namespaces from different application models are not used in the same application, so name collisions are less likely to affect developers using your library.

Infrastructure applications provide specialized support and are seldom referenced in program code. For example, the types in the *.Designer namespaces are used by program development tools. The *.Permissions namespaces are another example of infrastructure namespaces. Name collisions with types in infrastructure namespaces are unlikely to affect developers using your library.

The core namespaces are the System.* namespaces (excluding the application and infrastructure namespaces). System and System.Text are examples of core namespaces. You should make every effort to avoid name collisions with types in the core namespaces.

The namespaces belonging to a particular technology will have the same first and second level identifiers (Company.technology.*). You should avoid name collisions within a technology.

General Namespace Guidelines

Do not introduce generic type names such as Element, Node, Log, and Message. There is a very high probability it would lead to type name conflicts in common scenarios. You should qualify the generic type names (FormElement, XmlNode EventLog, SoapMessage).

Application Namespace Guidelines

Do not give the same name to types in namespaces within a single application model.

For example, if you were writing a library of special controls to be used by Windows forms application developers, you should not introduce a type named Checkbox because a type with this name already exists for the application model (CheckBox).

Core Namespace Guidelines

Do not give types names that would conflict with any type in the core namespaces.

For example, do not use Directory as a type name because this would conflict with the Directory type.

Technology Namespace Guidelines

Do not assign type names that would conflict with other types within a single technology.

Do not introduce type name conflicts between types in technology namespaces and an application model namespace (unless the technology is not intended to be used with the application model).

For more information on design guidelines, see the "Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries" book by Krzysztof Cwalina and Brad Abrams, published by Addison-Wesley, 2005.

Share via