在我的类库中使用“系统命名空间”是个好主意吗？
示例：
namespace System.Web {
public static class RequestExtensions {
public static bool IsPost(this HttpRequest r) {
return string.Compare(r.HttpMethod, "POST", StringComparison.OrdinalIgnoreCase) == 0;
}
}
}
优点：不需要包含额外的uses-clauses（特别是对于扩展方法），所以在添加对库的引用后，所有的都可以直接使用。
最好的示例是NUnitEx 项目（它使用 NUnit 的命名空间）。
缺点：潜在的名称冲突。
【问题讨论】：
标签： c# .net namespaces extension-methods
非常非常糟糕。这很令人困惑，只有在绝对必要时才应该这样做（在某些情况下需要这样做）。
只有在 100% 需要时才这样做，永远不要仅仅为了“方便”而这样做。
【讨论】：
使用基于系统的命名空间会使他人更难获取您的代码并弄清楚它在做什么。例如，如果我学习新的 C#，当我不知道某些东西时，我经常会在谷歌上搜索诸如“System.Web.xyz”之类的东西。
在这种情况下，我可能不知道“System.Web.RequestExtensions”不是 System.Web 命名空间的真正成员，所以我会在寻找一个不存在的类时陷入困境。
所以基本上，我的观点是您需要很好地记录它或找到另一个命名空间。
【讨论】：
我认为这不是一个好主意，因为微软可能会决定在下一个版本的框架中创建 RequestExtensions 类，最好用你的公司名称开始命名空间以防止名称冲突
【讨论】：
我必须支持所有说这是一个糟糕想法的人。命名空间是一个组织工具，在很多层面上。它们不仅允许您为自己的目的重复使用标识符而不会与其他公司发生冲突，它们还允许不同的公司将他们的产品与您或其他任何人的产品隔离开来。将代码放入 System 命名空间可能会让使用您的类型的人感到非常困惑。
此外，人们知道 System 命名空间中的任何内容都是来自 Microsoft 的良好、可靠、经过测试、社区审查、完整记录的代码。这是一组非常重要的因素......通过将您的代码粘贴在同一个命名空间中，您不仅声称您的代码很好，而且您必须不辜负它。
【讨论】：
设计指南谈namespace naming：
命名空间名称的一般格式如下：
<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]例如，Microsoft.WindowsMobile.DirectX。
在名称空间名称前加上公司名称以防止出现名称空间 来自具有相同名称和前缀的不同公司。
这里没有重复使用System 或Microsoft 的余地。
【讨论】：