命名空间的名称

与其他命名准则一样，命名命名空间的目标是让程序员使用框架立即知道命名空间的内容可能是什么。 以下模板指定命名命名空间的常规规则：

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

下面是一些示例：

Fabrikam.Math Litware.Security

✔️ DO 使用公司名称为命名空间名称添加前缀，以防止来自不同公司的命名空间具有相同名称。

✔️ 请在命名空间名称的第二级使用与版本无关的稳定产品名称。

❌ 请勿使用组织层次结构作为命名空间层次结构中名称的基础，因为公司内的组名称往往生存期较短。 围绕相关技术组组织命名空间的层次结构。

✔️ DO 使用帕斯卡命名法（PascalCasing），并使用句点分隔命名空间组件（例如，Microsoft.Office.PowerPoint）。 如果你的品牌采用非传统大小写，则应遵循品牌定义的大小写，即使它偏离了正常的命名空间大小写。

✔️ 请考虑在适当情况下使用复数命名空间名称。

例如，请使用 System.Collections 而不是 System.Collection。 但是，品牌名称和首字母缩略词是此规则的例外。 例如，请使用 System.IO 而不是 System.IOs。

❌ 请勿对命名空间和该命名空间中的类型使用相同的名称。

例如，不要 Debug 用作命名空间名称，然后还提供在同一命名空间中命名 Debug 的类。 多个编译器要求此类类型完全限定。

命名空间和类型名称冲突

❌请勿引入泛型类型名称，例如Element，NodeLog和Message。

这样做的概率非常高，这会导致常见方案中的类型名称冲突。 应限定泛型类型名称（FormElement、XmlNode、EventLog、SoapMessage）。

有一些特定的准则可以避免不同类别的命名空间的类型名称冲突。

• 应用程序模型命名空间

  属于单个应用程序模型的命名空间经常一起使用，但它们几乎永远不会用于其他应用程序模型的命名空间。 例如， System.Windows.Forms 命名空间很少与 System.Web.UI 命名空间一起使用。 下面是已知应用程序模型命名空间组的列表：

  System.Windows* System.Web.UI*

  ❌ 不要为单个应用程序模型中的命名空间中的类型提供相同的名称。

  例如，不要向Page命名空间添加一个名为System.Web.UI.Adapters的类型，因为System.Web.UI命名空间已包含一个名为Page的类型。

• 基础结构命名空间

  此组包含在开发常见应用程序期间很少导入的命名空间。 例如， .Design 命名空间主要用于开发编程工具。 避免与这些命名空间中的类型冲突并不至关重要。

• 核心命名空间

  核心命名空间包括所有 System 命名空间，不包括应用程序模型的命名空间和基础结构命名空间。 核心命名空间包括、System、System.IOSystem.Xml和System.Net。

  ❌ 请勿提供与核心命名空间中的任何类型冲突的类型名称。

  例如，永远不要将 Stream 用作类型名称。 它将与 System.IO.Stream一个非常常用的类型冲突。

• 技术命名空间组

  此类别包括具有相同的前两个命名空间节点 (<Company>.<Technology>*的所有命名空间，例如 Microsoft.Build.Utilities 和 Microsoft.Build.Tasks。 属于单个技术的类型不相互冲突非常重要。

  ❌ 请勿分配与单个技术中的其他类型冲突的类型名称。

  ❌ 请勿在技术命名空间和应用程序模型命名空间中引入类型名称冲突（除非技术不打算与应用程序模型一起使用）。

© 2005，2009 Microsoft Corporation 部分版权。 保留所有权利。

获得皮尔逊教育公司许可后重印自 框架设计准则：可重用 .NET 库的约定、习惯和模式 ，由 Krzysztof Cwalina 和 Brad Abrams 编写，并作为微软 Windows 开发系列中的出版物之一，于 2008 年 10 月 22 日由 Addison-Wesley Professional 出版。

另请参阅

• 框架设计准则
• 命名准则