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