为什么在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的运行时性能。
