为什么在 C# 中删除未使用的 using 指令？答案

【问题标题】：Why remove unused using directives in C#?为什么在 C# 中删除未使用的 using 指令？
【发布时间】：2010-10-12 09:28:30
【问题描述】：

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

【问题讨论】：

我相信这是 PowerCommands for Visual Studio 的一个特性，而不是 Visual Studio 本身的特性。
在 VS2008 中，它无疑是 VS 本身的一个特性（以及对 using 语句进行排序的能力）。
@Hosam：PowerCommands 使您能够为整个项目/解决方案做到这一点。对每个文件执行此操作是 VS 本身的一个特性。
顺便说一句，如果您想更精确地控制这种清理，请查看 Resharper。
我实际上真的很不喜欢这个功能——我总是发现自己在编辑一个文件并且必须在有人清理它们之后重新添加所有系统命名空间（通常是 System、System.Collections.Generic 和 System .Linq。）我发现它增加的摩擦比它节省的要多。现在，您自己的项目名称空间而不是框架名称空间 - 清理这些名称更有意义，以澄清程序的连接。希望有一种方法可以让 VS 只清理来自某些命名空间的导入，并保留您更频繁需要的系统。

标签： c# .net using

【解决方案1】：

代码编译速度更快。

【讨论】：

有任何证据支持吗？
哦，CK - 你又抓到我了。我撒了谎。删除不必要的文本实际上会使代码编译速度变慢。想想看：）
很高兴看到一些真实的统计数据。如果我们在编译时只节省几毫秒，那么速度就不是一个令人信服的论点。但是，还有其他原因可以删除不需要的 using 语句。
这不是说谎与否。任何明智的人都会猜测，更少的混乱意味着更高的效率。支持它的“证据”是为您的响应提供价值，并支持“更快”不仅仅意味着几毫秒的论点，实际上是一种改进的体验，可以更快地编译您的项目。
事实上，我为类、变量和方法编写了短名称，以使代码编译得更快。当我在尝试 First/FirstDefault/Single/Single/FirstOrEmpty/SingleOrSomething/DefaultWhenNull 时失去 1 分钟发现缺少使用 System.Linq 时......“WTF......我确信有一种方法......为什么我找不到？”或“为什么今天 Int32 不编译？？？”我认为 1 分钟的损失比在编译中获得的 1/1000 秒还要糟糕。

【解决方案2】：

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

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

另一方面，保留它们的理由并不多。我想您可以省去删除它们的麻烦。但如果你那么懒惰，你就有更大的问题了！

【讨论】：

一个好的程序员是懒惰的，他把不做的工作最大化。 :D
我不同意一个好的程序员是懒惰的，但我同意你的观点。一个好的程序员会删除它们以保持他的代码干净，从而避免他自己和他人未来的工作/问题/问题。
对，这是一个很棒的链接。我想我的观点只是我们想要“好懒”而不是“坏懒”；后者是程序员懒得写好代码的地方。
保留标准命名空间也有好处。在大型项目和团队中，保留它们会减少潜在的合并冲突，并减少用于代码审查的文件。此外，许多开发人员为事物添加了令人困惑且难以找到的扩展方法，有时为这些扩展方法定位所需的命名空间很麻烦。新开发人员可能习惯于将 System.Linq 包含在他们的代码文件中，并在寻求帮助之前浪费大量时间试图找出某些方法不可用的原因。
你可能想保留其中一些，以防止智能感知在未来的编码中变得愚蠢。

【解决方案3】：

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

假设您必须在 3、6、9 个月后重新使用您的代码 - 或者其他人必须接管您的代码并进行维护。

如果您有一长串实际上并不需要的 using 语句，那么查看代码可能会令人困惑。如果该命名空间中没有使用任何内容，为什么要在其中使用？？

我想就专业环境中的长期可维护性而言，我强烈建议让您的代码尽可能干净——这包括从中倾倒不必要的东西。更少的混乱等于更少的混乱，从而提高了可维护性。

马克

【讨论】：

【解决方案4】：

IntelliSense 弹出窗口中的选项较少（特别是在命名空间包含大量扩展方法时）。

理论上 IntelliSense 也应该更快。

【讨论】：

+1 用于智能感知。启动时它实际上很慢（我经常看到“构建缓存，稍后再试”），所以这实际上可能很重要。其他人都在谈论的编译时间……我还没有看到数字。

【解决方案5】：

在我看来，这是一个非常明智的问题，但回答的人却以相当轻率的方式对待这个问题。

我想说对源代码的任何更改都需要证明是合理的。这些变化可能会产生隐性成本，提出问题的人希望了解这一点。他们并没有要求被称为“懒惰”，正如一个人所暗示的那样。

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

我们使用自动构建过程，因此对我们的 SVN 存储库的任何更改都会产生我们无法链接到项目/错误/问题的更改，并且会触发自动构建和发布，而不会对以前的版本进行任何功能更改。

如果我们考虑删除冗余限定符，这可能会给开发人员造成混淆，因为我们的域和数据层中的类仅由限定符区分。

如果我查看过时词大写的正确使用（即 ABCD -> Abcd），那么我必须考虑到 ReSharper 不会重构我们使用引用类名的任何 Xml 文件。

因此，遵循这些提示并不像看起来那么简单，应该受到尊重。

【讨论】：

好点，但您也不应该忘记维护干净简单的代码可以提高可维护性，这也是一个业务目标。你必须权衡两者。理想情况下，您希望在发布后立即进行此类重构，这样您就可以有一个尽可能干净的板子来开始一个新的，并有足够的时间来捕捉最终的回归。

【解决方案6】：

它还有助于防止错误的循环依赖，假设您在删除未使用的使用后还能够从项目中删除一些 dll/项目引用。

【讨论】：

【解决方案7】：

删除它们。更少的代码查看和思考可以节省时间和混乱。我希望更多的人能保持简单、整洁和整洁。这就像在你的房间里有脏衬衫和裤子。它很丑，你必须想知道它为什么在那里。

【讨论】：

【解决方案8】：

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

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;这一行。

【讨论】：

【解决方案9】：

至少在理论上，如果给您一个 C# .cs 文件（或任何单个程序源代码文件），您应该能够查看代码并创建一个模拟所需一切的环境。通过一些编译/解析技术，您甚至可以创建一个工具来自动完成它。如果您至少记住了这一点，那么您可以确保您理解代码文件所说的所有内容。

现在考虑一下，如果给你一个 .cs 文件，其中包含 1000 个 using 指令，而实际上只使用了 10 个指令。每当您查看引用外部世界的代码中新引入的符号时，您将不得不通过这 1000 行来弄清楚它是什么。这显然减慢了上述过程。因此，如果您可以将它们减少到 10 个，将会有所帮助！

在我看来，C# using 指令非常弱，因为你不能指定单个泛型符号而不丢失泛型，并且你不能使用using 别名指令来使用扩展方法。在 Java、Python 和 Haskell 等其他语言中情况并非如此，在这些语言中，您可以（几乎）准确地指定您想要从外部世界得到什么。但即便如此，我还是建议尽可能使用using 别名。

【讨论】：

【解决方案10】：

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

假设您有两个程序集，其中一个引用另一个（现在让我们调用第一个 A 和引用的 B）。现在，当您在 A 中有依赖于 B 的代码时，一切都很好。然而，在您的开发过程中的某个阶段，您注意到您实际上不再需要该代码，但您将 using 语句留在原处。现在你不仅有一个无意义的using-directive，而且还有一个B 的assembly-reference，除了在过时的指令中，它没有在任何地方使用。这首先会增加编译A 所需的时间，因为还必须加载B。

因此，这不仅是一个关于更清洁、更易于阅读的代码的问题，而且也是在生产代码中维护程序集引用的问题，其中并非所有引用的程序集都存在。

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

【讨论】：