为什么要删除不必要的C＃使用指令？
例如，我很less需要：
using System.Text; 但总是默认的 如果您的代码包含不必要的使用指令，我认为应用程序将使用更多的内存。 但是还有什么我应该知道的？
另外，如果仅在一个文件中使用相同的使用指令而不是大多数/所有文件，它是否会有所作为？
编辑：请注意，这个问题不是关于不相关的概念称为使用语句 ，旨在通过确保当一个对象超出范围时，调用其IDisposable.Dispose方法来帮助pipe理资源。 请参阅C＃中“using”的使用 。
程序运行时不会改变任何东西。 所有需要的东西都是按需加载的。 所以，即使你有这个使用语句，除非你真的在这个名字空间/程序集中使用了一个types，那么使用语句相关的程序集将不会被加载。
主要是清理个人喜好。
删除未使用的使用（s）/名称空间的原因很less，除了编码优先select之外：
- 删除项目中未使用的using子句可以使编译速度更快，因为编译器只有更less的名称空间才能parsing查找types。 （对于C＃3.0，尤其如此，因为扩展方法，编译器必须search所有名称空间以获得可能更好匹配的扩展方法，genericstypes推断和涉及genericstypes的lambdaexpression式）
- 当将新types添加到与已用名称空间中的某些types具有相同名称的未使用名称空间时，可能有助于避免在将来的构build中发生名称冲突。
- 编码时会减less编辑器自动完成列表中的项目数量，可能导致更快的input（在C＃3.0中，这也可以减less显示的扩展方法列表）
什么删除未使用的名称空间不会这样做：
- 以任何方式改变编译器的输出。
- 以任何方式改变编译程序的执行（加载更快，或性能更好）。
生成的程序集是相同的或不使用（s）删除。
代码清洁很重要。
当人们看到多余的使用情况时，人们开始感觉到代码可能无法维持，并且在浏览器的path上。 实质上，当我看到一些未被使用的使用陈述时，我脑后出现一个小黄旗，告诉我“谨慎行事”。 阅读产品代码不应该给你那种感觉。
所以清理你的用途。 不要马虎。 激发信心。 让你的代码漂亮。 给另一个开发者一个温暖的模糊感觉。
没有IL结构对应于using 。 因此， using语句不会增加您的应用程序内存，因为没有为其生成代码或数据。
仅在编译时Using使用”才能将短types名称parsing为完全限定的types名称。 因此，不必要的唯一的负面影响是可以减less编译时间，并在编译过程中占用更多的内存。 我不会为此担心的。
因此， using你不需要的语句的唯一真正的负面影响是在智能感知上，因为在你input的时候，完成的潜在匹配匹配增加了。
如果在名称空间中调用像类（未使用）类的类，则可能会发生名称冲突。 在System.Text的情况下，如果您定义了一个名为“Encoder”的类，就会遇到问题。
无论如何，这通常是一个小问题，并由编译器检测到。
你的应用程序不会使用更多的内存。 它的编译器find您在代码文件中使用的类。 这真的不会伤害，除非不干净。
主要是个人喜好。 我自己清理它们（Resharper做了一个很好的告诉我什么时候不需要使用语句）。
有人可能会说，这可能会缩短编译时间，但是现在用计算机和编译器的速度，它不会有任何明显的影响。
留下额外的using指令是好的。 去除它们有一点价值，但不是很多。 例如，它使我的智能感知完成列表更短，因此更容易导航。
编译的程序集不受外来using指令的影响。
有时我把它们放在一个#region ，让它崩溃了。 这使得查看文件更清洁。 国际海事组织，这是#regionless数良好的用途之一。
他们只是作为一个捷径。 例如，如果您没有使用System，则必须每次都写入：System.Int32; 在上面。
删除未使用的只是让你的代码看起来更干净。
使用声明只是让你不符合你使用的types。 我个人喜欢清理它们。 真的这取决于如何使用loc度量标准
只有你实际使用的命名空间可以让你保持你的代码logging。
你可以很容易地find你的代码的哪些部分通过任何search工具相互呼叫。
如果你有没有使用的名称空间，这意味着什么，在运行search。
现在我正在清理命名空间，因为我总是被问到应用程序的哪些部分以这种或那种方式访问相同的数据。
由于数据访问被名称空间分隔，例如直接通过数据库和直接通过Web服务，我知道哪些部分正在访问数据。
我想不出一个简单的方法来一次完成这一切。
如果你只是想让你的代码成为黑箱（对开发人员），那么是没关系的。 但是，如果你需要保持一段时间，这是有价值的文件像所有其他的代码。
“using”语句不会影响性能，因为它只是帮助您定义标识符的名称。 因此，如果您使用System.IO ，则不必inputSystem.IO.Path.Combine（…） ，只需键入Path.Combine（…）即可 。
不要忘记，编译器在构build项目时会做很多工作来优化所有的东西。 使用它在很多地方使用或1不应该做一个不同的编译。
