为什么在C#中删除未使用的使用指令?

我想知道是否有任何理由(除了整理源代码)为什么开发人员使用Visual Studio 2008中的“删除未使用的使用”function?

有几个原因你想要把它们拿出来。

  • 没有用。 他们没有增值。
  • 这很混乱。 从那个名字空间使用什么?
  • 如果你不这样做,那么随着时间的推移,你的代码会随着代码的变化而逐渐累积起来。
  • 静态分析较慢。
  • 代码编译速度较慢。

另一方面,没有太多的理由让他们进来。我想你可以省去删除它们的努力。 但是如果你那么懒,你就会遇到更大的问题!

我想说的恰恰相反 – 删除不必要的,不必要的使用语句非常有帮助。

想象一下,你必须在3,6,9个月内回到你的代码 – 否则别人必须接pipe你的代码并维护它。

如果你有一个很长的使用陈述,并不是真的需要,那么查看代码可能会让人感到困惑。 为什么在那里使用,如果从这个名字空间没有使用?

我认为,在专业环境下的长期可维护性方面,我强烈build议尽可能保持代码清洁 – 包括从其中倾销不必要的东西。 减less混乱等于减less混乱,从而提高可维护性。

渣子

在我看来,这是一个非常明智的问题,人们的反应是相当轻率的。

我会说任何源代码的改变都需要certificate。 这些变化可能会带来隐藏的代价,提出这个问题的人希望能够意识到这一点。 他们并不要求被称为“懒惰”,作为一个人的animation。

我刚刚开始使用Resharper,并开始对我负责的项目发出警告和样式提示。 其中包括删除冗余使用指令,也包括冗余限定符,大写字母等等。 我的直觉是清理代码并解决所有的提示,但是我的业务主pipe警告我不要有不合理的改变。

我们使用自动构build过程,因此,对SVN存储库的任何更改都会导致无法链接到项目/错误/问题的更改,并且会触发自动构build和发布,而不会对先前版本进行function更改。

如果我们考虑删除冗余限定符,这可能会导致开发人员的混淆,因为我们的域和数据层只能通过限定符来区分。

如果我正确地使用大写字母(即ABCD – > Abcd),那么我必须考虑到Resharper不会重构我们使用这个引用类名的任何Xml文件。

所以,遵循这些提示并不像看起来那么直截了当,应该受到尊重。

Intellisensepopup窗口中的选项较less(特别是如果名称空间包含许多扩展方法)。

智能感知理论上也应该更快。

除了已经给出的原因之外,它防止了不必要的命名冲突。 考虑这个文件:

 using System.IO; using System.Windows.Shapes; namespace LicenseTester { public static class Example { private static string temporaryPath = Path.GetTempFileName(); } } 

此代码不会编译,因为两个命名空间System.IO和System.Windows.Shapes都包含一个称为path的类。 我们可以通过使用完整的类path来修复它,

  private static string temporaryPath = System.IO.Path.GetTempFileName(); 

或者我们可以简单地using System.Windows.Shapes;删除行using System.Windows.Shapes;

删除它们。 更less的代码来看待和想知道节省时间和困惑。 我希望更多的人能够保持简单,完美和清洁。 这就像在你的房间里有脏衬衫和裤子。 这是丑陋的,你必须想知道为什么它在那里。

它还有助于防止错误的循环依赖,假设你也可以在删除未使用的用户之后从项目中删除一些dll /项目引用。

代码编译速度更快。

至less从理论上讲,如果你得到一个C#.cs文件(或者任何单一的程序源代码文件),你应该能够查看代码并创build一个模拟所需的一切的环境。 使用一些编译/parsing技术,你甚至可以创build一个工具来自动完成。 如果你至less想到这一点,你可以确保你了解代码文件所说的一切。

现在考虑一下,如果你给了一个带有1000条using指令的.cs文件,其中只有10条是实际使用的。 每当你看到代码中引用外部世界时新引入的符号,你将不得不通过1000行来弄清楚它是什么。 这显然是减缓了上述过程。 所以如果你能把他们减less到10,这将有助于!

在我看来,C# using指令是非常薄弱的​​,因为你不能指定单一的通用符号没有generics丢失,你不能使用别名指令使用扩展​​方法。 在Java,Python和Haskell等其他语言中,情况并非如此,在这些语言中,您几乎可以明确地从外部指定您想要的内容。 但事件,我会build议尽可能using别名。

最近我有另一个原因,删除未使用的import是相当有益的和重要的。

想象一下,你有两个组件,其中一个引用另一个(现在让我们称之为第一个A和引用的B )。 现在,当你有代码在A取决于B一切都很好。 然而,在开发过程中的某个阶段,您注意到您实际上不再需要该代码,而是将使用声明保留在原来的位置。 现在你不仅有一个毫无意义的使用指令,而且还提到了一个在任何地方都没有使用过的B引用 ,但是在过时的指令中。 这首先减less了编译A所需的时间,同时B也必须被加载。

所以这不仅是一个更清洁,更容易阅读代码的问题,而且也是在生产代码中维护汇编引用的地方,而不是所有这些引用的汇编甚至都存在

最后,在我们的实践中,我们必须将B和A一起运送,尽pipeB在A中的任何地方都没有使用,但是在使用部分中。 这将在加载参考时大量影响A的运行时性能。