Question

很久以前，我记得读过微软强烈反对将自己的类添加到框架命名空间的建议。我找不到它了。

我记得的主要原因是框架的后续版本可能附带了类名冲突。

还有其他原因吗？您是否建议将自己的类添加到框架命名空间？关于此事，是否有任何现存的官方指导？

Answer 1

似乎很清楚here：

命名约定

.NET Framework类型使用点语法命名方案，该方案表示层次结构。此技术将相关类型分组到命名空间中，以便可以更轻松地搜索和引用它们。全名的第一部分 - 最右边的点 - 是命名空间名称。名称的最后一部分是类型名称。例如，System.Collections.ArrayList表示ArrayList类型，它属于System.Collections命名空间。 System.Collections中的类型可用于操纵对象集合。

这种命名方案使扩展.NET Framework的库开发人员可以轻松创建类型的分层组，并以一致，信息丰富的方式命名它们。它还允许通过全名（即名称空间和类型名称）明确标识类型，从而防止类型名称冲突。在为名称空间创建名称时，预计库开发人员将使用以下指南：
CompanyName.TechnologyName
例如，命名空间Microsoft.Word符合本指南。

"Design Guidelines for Developing Class Libraries"带有类似的规则：

命名空间名称的一般格式如下：
<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]
例如，Microsoft.WindowsMobile.DirectX。

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

执行在命名空间名称的第二级使用稳定的，与版本无关的产品名称。

执行不使用组织层次结构作为命名空间层次结构中名称的基础，因为公司内的组名往往是短暂的。

命名空间名称是一个长期存在且不变的标识符。随着组织的发展，更改不应使命名空间名称过时。

执行使用Pascal大小写，并使用句点分隔名称空间组件（例如，Microsoft.Office.PowerPoint）。如果您的品牌采用非传统外壳，您应该遵循您的品牌定义的外壳，即使它偏离了正常的命名空间外壳。

考虑在适当的地方使用多个命名空间名称。例如，使用System.Collections代替System.Collection。然而，品牌名称和首字母缩略词是此规则的例外。例如，使用System.IO代替System.IOs。

不要对命名空间使用相同的名称，并在该命名空间中使用类型。例如，不要将Debug用于命名空间名称，还要在同一命名空间中提供名为Debug的类。一些编译器要求这些类型完全合格。

和

核心命名空间是System。*命名空间（不包括应用程序和基础结构命名空间）。 System和System.Text是核心命名空间的示例。您应该尽一切努力避免与核心命名空间中的类型发生名称冲突。

执行不提供与核心命名空间中的任何类型冲突的类型名称。

例如，不要将Directory用作类型名称，因为这会与Directory类型冲突。

但是，当然，你can do it if you really want to。

Answer 2

当您尝试存根不再存在的东西时，您希望在不属于您的命名空间中拥有类的唯一情况但是在您不想更改的代码库中使用

例如，我编写了一个HashSet实现，并放置在System.Collections.Generic命名空间中，用于.NET 3.5处于测试阶段时针对.NET 2.0的应用程序。我知道我们将升级到.NET 3.5并在时机成熟时删除此类。

Answer 3

建议使用Company.Product.Component作为命名空间。这可能包括我认为不在您自己的产品中使用Framework命名空间。请参阅MSDN: Names of Namespaces (Design Guidelines for Developing Class Libraries )。

就我个人而言，我永远不会将System命名空间用于我自己的类，就像它们不属于.NET框架一样。我都不会在Java中使用java.lang。但是，这只是我个人的意见。

希望有所帮助。

干杯，马蒂亚斯

向框架命名空间添加新类是一种好习惯吗？

3 个答案:

命名约定