22.4 Namespaces

The general pattern to follow when naming namespaces is:


Some examples of well-formed namespaces are:


One problem that may arise, particularly as more companies begin to write code for the .NET platform, is that the "company-level" namespaces may clash. Java sought to avoid this problem by strongly suggesting companies use their reverse-DNS name ("oreilly.com" produces "com.oreilly" top-level namespace names), since DNS names are guaranteed to be unique. Over time, however, this proved to be less of an issue than originally thought, and many companies began to use the "center" name in the DNS name (for instance "oreilly" in "oreilly.com"). There is no reason to believe this convention won't continue to work in .NET.

For legibility, use Pascal case, and separate logical components with periods (for example, Microsoft.Office.PowerPoint). However, if your product involves nontraditional capitalization, it's okay to use that system, even if it deviates from normal namespace casing (for example NeXT.WebObjects, OReilly.Network and ee.cummings).

Plural namespace names are recommended where appropriatefor example, use System.Collections, not System.Collection. Exceptions to this rule are brand names and abbreviationsfor example, use System.IO, not System.IOs.

Never reuse names across namespace and class namesfor example, the System.Debug namespace should never have a class named Debug within it. (Naturally, this is scoped to the namespace itself; it is perfectly acceptable to have a class called Debug in the System.IO namespace.)

    Part II: Programming with the .NET Framework
    Part IV: API Quick Reference