命名空间的名称
为命名空间选择的名称应指示命名空间中的类型所提供的功能。 例如，System.Net.Sockets 命名空间包含的类型允许开发人员使用套接字通过网络进行通信。
命名空间名称的一般格式如下：
<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]
例如 Microsoft.WindowsMobile.DirectX。
使用公司名称作为命名空间的前缀以防止不同公司开发的命名空间具有相同的名称和前缀。
在命名空间名称的第二级使用稳定的、与版本无关的产品名称。
不要根据组织层次结构确定命名空间层次结构中的名称，因为公司的部门名称经过一段时间后可能会改变。
命名空间名称是长期使用的、不会更改的标识符。 组织的不断发展和变化不应使命名空间名称过时。
使用 Pascal 大小写格式，并用句点分隔命名空间各部分（如 Microsoft.Office.PowerPoint）。 如果您的品牌采用了非传统的大小写，应遵循您的品牌所定义的大小写，即使它与常用的命名空间大小写相背离也如是。
适当的时候可考虑使用复数命名空间名称。 例如，使用 System.Collections，而不要使用 System.Collection。 但是，品牌名称和首字母缩写词属于此规则的例外情况。 例如，使用 System.IO，而不要使用 System.IOs。
命名空间和其中的类型不要使用相同的名称。 例如，不要在将“Debug”用作命名空间名称的同时，又在该命名空间中提供一个名为“Debug”的类。 有些编译器要求对这种类型进行完全限定。
命名空间和类型的名称冲突
如果选择的命名空间或类型的名称与现有名称冲突，则库的用户将不得不对受影响的项的引用进行限定。 在大多数开发情况中，都不应出现这种问题。
本节提供的某些准则适用于下面的命名空间类别：
应用程序模型命名空间
基础结构命名空间
核心命名空间
技术命名空间组
应用程序模型中的命名空间提供特定于应用程序中的某个类的功能集。 例如，System.Windows.Forms 命名空间中的类型提供编写 Windows 窗体客户端应用程序所需的功能。 System.Web 命名空间中的类型支持编写基于 Web 的服务器应用程序。 通常，在同一应用程序中不会使用不同应用程序模型中的命名空间，因此，这降低了名称冲突影响使用您的库的开发人员的可能性。
基础结构应用程序提供专门的支持，很少在程序代码中进行引用。 例如，程序开发工具所使用的 *.Designer 命名空间中的类型。 *.Permissions 命名空间是基础结构命名空间的另一个示例。 与基础结构命名空间中的类型的名称冲突不可能影响使用您的库的开发人员。
核心命名空间为 System.* 命名空间（不包括应用程序命名空间和基础结构命名空间）。 System 和 System.Text 都是核心命名空间的示例。 应尽可能避免与核心命名空间中的类型发生名称冲突。
属于特定技术的命名空间将具有相同的第一和第二级标识符 (Company.technology.*)。 应避免在技术命名空间中出现名称冲突。
命名空间一般准则
不要引入宽泛的类型名称，如 Element、Node、Log 和 Message。 在通常情况下，这样极可能导致类型名称冲突。 应对宽泛的类型名称进行限定（例如 FormElement、XmlNode EventLog、SoapMessage）。
应用程序命名空间准则
不要在单个应用程序模型内为命名空间中的多个类型指定相同的名称。
例如，如果要编写 Windows 窗体应用程序开发人员要使用的特殊控件库，则不应引入名为 Checkbox 的类型，因为该应用程序模型已存在同名类型 (CheckBox)。
核心命名空间准则
不要指定会与核心命名空间中的任何类型发生冲突的类型名称。
例如，不要使用 Directory 作为类型名称，因为这会与 Directory 类型冲突。
技术命名空间准则
不要分配会与单个技术命名空间内的其他类型发生冲突的类型名称。
不要引入会导致技术命名空间的类型与应用程序模型命名空间中的类型发生冲突的类型名称（除非该技术不用于该应用程序模型）。
部分版权所有 2005 Microsoft Corporation。 保留所有权利。
部分版权所有 Addison-Wesley Corporation。 保留所有权利。
设计指引的详细信息，请参阅"框架设计准则： 公约、 成语和可重复使用的模式。网络图书馆"书 Krzysztof Cwalina 和布拉德 · 艾布拉姆斯，2005年艾迪生 － 韦斯利，发表。