.NET 指南：命名空间的名称

已选择的命名空间名称应该可以表示功能能够通过对命名空间中的类型进行引用的方式而变得可用。例如，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 类型相冲突。

技术命名空间指导方针不要指定将与一个单独的技术中的其他类型相冲突的类型名称。不要引入在技术命名空间中和应用程序模型命名空间（除非技术并不是有意在应用程序模型中被使用的）中的类型之间相冲突的类型名称。