在系统命名空间中放置自定义代码

这不是一个好主意,因为它破坏了名称空间的一个主要好处:防止名称冲突。如果框架的较新版本在该命名空间中引入了一个同名类型,该怎么办?

这对 System 命名空间,因为它们是在许多其他代码段中导入的, using 指令和在这些命名空间中引入自定义类型会使用意外的标识符污染其他源文件的命名范围。

要对自定义互操作相关类型进行分类,可以创建一个新的命名空间,如 MyProduct.InteropServices .

如果你上新课 System.InteropServices ,每个文件 using System.InteropServices; 子句被强制将类放在作用域中,这可能会混淆程序员。因为程序员不能为自己辩护,所以我认为这是一个糟糕的实践。

我不同意每个人的意见。

我认为在有限的情况下(主要是使用扩展方法),将代码放在系统名称空间中是完全合理的。

这是我们在系统命名空间中讨论扩展方法的一个电子邮件线程的论点的一部分。 EPS :

好吧,我的观点是:

1. 我真的很喜欢最小化代码。包括使用。

2. 是的,resharper会选择扩展方法并为您添加using,但有些人没有resharper,而且我更喜欢coderush,到目前为止,它实际上(据我所知)还没有获取扩展名称空间。

3. 至少有两种不同类型的扩展方法;一种是应用程序的辅助方法,包括域和特定于应用程序的辅助方法,另一种是封装我们认为语言应该从中开始的特性和语法的方法。

后者的一个很好的例子是 "a {0} {1}".Format("b", "c") 或 someListOfStrings.Join(", ") 而不是必须这么做 String.Join(someStringList.ToArray(), ", ") . 其他更有争议的例子是 IEnumerable<T>.ForEach 以及 IsNull() 取代笨手笨脚的扩展 object.ReferenceEquals(null, someVar) 语法。

我的观点是,有充分的理由将后一种分类放在适当的名称空间(system、system.io、system.linq等)中—您的团队大致同意应该使用语言,但不使用语言。我们希望这些函数在任何地方都可用,就像我们希望foreach和yield关键字始终可见一样。如果它是特定于应用程序的,那么它应该进入自己的名称空间。90%的时间特定于应用程序的助手扩展不应该是扩展,甚至不应该是静态的。我使用扩展方法从该语句中排除,以提供函数名的别名。

当然,当调用包含系统范围扩展的程序集时,可能会遇到一些问题。假设我引用的程序集包含我的空 IEnumerable<t>。foreach 方法,并希望创建自己的类Ruby R IEnumerable<T, R>.ForEach (实际上只是一种选择,但决不允许这样做)。这是个问题!我想做的是减轻这个问题,将我的扩展类定义为内部类,以便它们只能用于我的项目。这很好地解决了问题。