为什么要删除C＃中未使用的using指令？

120

我想知道是否有任何原因（除了整理源代码之外），为什么开发人员会Usings在Visual Studio 2008中使用“删除未使用的”功能？

c# .net using

— 布纳夫
source

我认为这是PowerCommands for Visual Studio的功能，而不是Visual Studio本身的功能。

— Hosam Aly

3

在VS2008中，它无疑是VS本身的一项功能（以及对using语句进行排序的功能）。

— 理查德

1

@Hosam：PowerCommands使您可以对整个项目/解决方案执行此操作。对每个文件执行此操作是VS本身的功能。

— 配置器

3

顺便说一句，如果您想对这种清理进行更精确的控制，请查看Resharper。

— 约翰·费米内拉

2

我实际上真的不喜欢此功能-我总是发现自己正在编辑文件，并且在有人清理了它们（通常是System，System.Collections.Generic和System.Linq。）之后不得不重新添加所有System命名空间。摩擦多于节省。现在，您自己的项目名称空间而不是框架名称空间-清理这些名称空间更有意义，以澄清程序的连接。希望有一种方法可以让VS仅清除某些命名空间中的导入，并保留您更经常需要的System命名空间。

— user1454265'2

186

您有几个理由要删除它们。

这是毫无意义。他们没有任何价值。
令人困惑。该名称空间正在使用什么？
如果不这样做，则using随着代码随时间的变化，您将逐渐积累无意义的语句。
静态分析较慢。
代码编译较慢。

另一方面，没有太多理由要保留它们。我想您可以省去删除它们的工作。但是，如果您这么懒，就会遇到更大的问题！

— 约翰·费米内拉
source

59

一个好的程序员很懒惰，他最大化了不做的工作。：D

— Nicolas Dorier 09年

34

我不同意一个好的程序员是懒惰的，但是我同意你的观点。一个好的程序员会删除它们，以保持其代码的干净，从而避免自己和他人将来的工作/问题/问题。

— Allan

2

是的，那是一个很好的联系。我想我的意思是，我们要“好懒”而不是“坏懒”。后者是程序员不必费心编写好的代码的地方。

— 艾伦2012年

5

也有保留标准名称空间的优点。在大型项目和团队中，将它们留在结果中会减少潜在的合并冲突，并减少用于代码审查的文件。另外，许多开发人员在事情上增加了混乱且难以找到扩展方法，有时为这些扩展方法查找所需的名称空间是一件麻烦的事。新开发人员可能已经习惯于将System.Linq包含在他们的代码文件中，并浪费大量时间试图弄清楚为什么某些方法在寻求帮助之前不可用。

— Mark At Ramp51

5

您可能想保留其中的一些，以防止智能感知在以后的编码中变得愚蠢。

— yazanpro

24

我要说的恰恰相反-删除不需要的，不必要的using语句非常有帮助。

想象一下，您必须在3、6、9个月内重新使用代码-否则其他人必须接管您的代码并进行维护。

如果您确实不需要大量庞大的using语句，那么查看代码可能会造成混乱。如果在该名称空间中未使用任何内容，为什么要在其中使用它？

我想就专业环境中的长期可维护性而言，我强烈建议您保持代码尽可能的干净-包括从中丢弃不必要的内容。更少的杂物等于更少的混乱，因此维护性更高。

马克

— marc_s
source

14

在我看来，这是一个非常明智的问题，响应的人们正在以一种非常轻率的方式来对待它。

我想说，对源代码的任何更改都必须是合理的。这些更改可能会带来隐性成本，因此提出问题的人员希望对此有所了解。正如一个人暗示的那样，他们没有要求被称为“懒惰”。

我刚刚开始使用Resharper，并且它开始在我负责的项目中提供警告和样式提示。其中包括删除多余的using指令，以及多余的限定符，大写字母等。我的直觉是整理代码并解决所有提示，但是我的业务负责人警告我不要进行不合理的更改。

我们使用自动构建过程，因此对SVN信息库的任何更改都会生成我们无法链接到项目/错误/问题的更改，并会触发自动构建和发行，而这些功能对以前的版本没有任何功能性更改。

如果我们考虑删除多余的限定符，则可能会导致开发人员感到困惑，因为我们的域和数据层仅由限定符区分。

如果我正确地使用了反名的大写形式（即ABCD-> Abcd），那么我必须考虑到Resharper不会重构我们使用该引用类名称的任何Xml文件。

因此，遵循这些提示并不像看起来那样简单明了，应予以尊重。

6

好点，但是您也不要忘记，保持简洁的代码可以增强可维护性，这也是一个业务目标。您必须权衡两者。理想情况下，您希望在发布后立即进行此类重构，以便您可以拥有尽可能干净的板块来开始新的构建，并有足够的时间来捕获最终的回归。

— David Reis 2010年

14

除了已经给出的原因之外，它还可以防止不必要的命名冲突。考虑以下文件：

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的类。我们可以使用完整的类路径来解决它，

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

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

— 超人
source

13

Intellisense弹出窗口中的选项较少（特别是如果名称空间包含很多Extension方法）。

从理论上讲，Intellisense也应该更快。

— 现金流量
source

1

+1代表智慧。它实际上在启动时很慢（我经常看到“正在构建缓存，请稍后再试”），因此这实际上很重要。编译其他人都在谈论的时间...我还没有看到数字。

— 卢克，

5

删除它们。更少的代码可以查看，不知道会节省时间和混乱。我希望更多的人能保持简单，整洁和整洁。就像在房间里穿脏衬衫和裤子一样。这很丑，您必须怀疑为什么它在那里。

— 蒂姆·邓肯
source

4

假设您还可以在删除未使用的用法后从项目中删除一些dll /项目引用，这也有助于防止错误的循环依赖关系。

— 杰里米·C。
source

3

代码编译速度更快。

— 死账
source

5

有任何证据来证明这一点吗？

— cjk

14

哦，CK-你又把我抓出来了。我撒了谎。删除不必要的文本实际上会使代码编译变慢。考虑一下:)

— 死账

@ck：我已经验证了在工作中从项目中删除未使用的using语句可以显着提高编译时间。当然会-从硬盘读取更少的字节。

— 配置器

19

希望能看到一些真实的统计数据。如果我们在编译时仅节省了几毫秒，那么速度并不是一个引人注目的参数。但是，还有其他一些原因可以删除不需要的using语句。

— 格雷格，2009年

3

这与撒谎与否无关。任何明智的人都会猜测，减少混乱意味着更高的效率。支持它的“证据”是为您的响应提供价值并支持“更快”不仅仅意味着几毫秒的说法，而是一种可以更快地编译项目的改进体验。

— Matheus Felipe

3

最近，我有了另一个原因，为什么删除未使用的导入非常有帮助且很重要。

假设您有两个程序集，其中一个程序集引用另一个程序集（现在让我们称为第一个程序集A和被引用的B）。现在，当您在A中有依赖于B的代码时，一切都很好。但是，在开发过程的某个阶段，您会发现实际上不再需要该代码，但是将使用状态保留在原处。现在，您不仅有一个无意义的指令，using而且还有一个汇编引用，B该引用在任何地方都没有使用，而已在过时的指令中使用。首先，这会增加编译所需的时间A，因为B也必须加载。

因此，这不仅是更清晰易读的代码的问题，而且还涉及在生产代码中维护程序集引用的问题，因为即使不是所有引用的程序集也都存在。

最后，在示例中，我们不得不将B和A一起运送，尽管B在A部分的任何地方都没有使用，而是在-部分中使用了using。这将极大地影响加载程序集时的运行时性能。A

— HimBromBeere
source

2

至少从理论上讲，如果为您提供了C＃.cs文件（或任何单个程序源代码文件），则您应该能够查看代码并创建一个模拟其所需内容的环境。使用某些编译/解析技术，您甚至可以创建一个自动执行此操作的工具。如果至少是由您自己决定的，则可以确保您了解代码文件所说的所有内容。

现在考虑，如果为您提供了带有1000 using条指令的.cs文件，而实际上仅使用了10条。每当您查看引用外部世界的代码中新引入的符号时，都必须遍历这1000行以弄清楚它是什么。这显然会减慢上述过程。因此，如果您可以将它们减少到10个，这将有所帮助！

我认为C＃using指令非常弱，因为您不能在不丢失通用性的情况下指定单个通用符号，并且不能使用using别名指令来使用扩展方法。在其他语言（例如Java，Python和Haskell）中则不是这种情况，在这些语言中，您可以（几乎）准确地指定外界想要什么。但是，那么，我建议尽可能使用using别名。

— 地球引擎
source