为什么要使用指令删除不必要的C＃？

例如，我很少需要：

using System.Text;

但默认情况下它始终存在。我假设如果您的代码包含不必要的using指令，则应用程序将使用更多内存。但是我还有什么需要注意的吗？

另外，如果仅在一个文件中对大多数文件/所有文件使用相同的using指令，是否有任何区别？

编辑：请注意，此问题与称为using语句的无关概念无关，该语句旨在通过确保当对象超出范围时调用其IDisposable.Dispose方法来帮助管理资源。请参见C＃中“使用”的用法。

当您的程序运行时，它不会改变任何内容。所需的一切均按需加载。因此，即使您具有using语句，除非您实际上在该名称空间/程序集中使用了类型，否则将不会加载using语句所关联的程序集。

主要是为了个人喜好进行清理。

有是用于删除未使用的使用（S）/命名空间，除了编码偏好几方面的原因：

• 删除项目中未使用的using子句，可以加快编译速度，因为编译器具有较少的名称空间来查找要解析的类型。（由于扩展方法，对于C＃3.0尤其如此，编译器必须在所有命名空间中搜索扩展方法以寻找可能的更好匹配，泛型类型推断和涉及泛型类型的lambda表达式）
• 将新类型添加到未使用的名称空间中的名称与使用的名称空间中的某些类型相同的名称时，可以潜在地避免将来版本中的名称冲突。
• 会减少编码时编辑器自动完成列表中的项目数量，有可能导致更快的键入速度（在C＃3.0中，这也可以减少显示的扩展方法列表）

删除未使用的名称空间将无法执行以下操作：

• 以任何方式更改编译器的输出。
• 以任何方式改变编译程序的执行（更快的加载或更好的性能）。

删除或不删除未使用的组件时，所得组件相同。

代码清洁度很重要。

当人们看到多余的用法时，人们开始感到代码可能无法维护，并且会出现在眉毛上。本质上，当我看到一些未使用的using语句时，我的大脑后面会升起一个黄色的小旗，告诉我“谨慎行事”。阅读生产代码绝对不会给您那种感觉。

因此，清理您的用法。不要马虎。激发信心。使代码漂亮。给另一个开发人员一种温暖的感觉。

没有与对应的IL构造using。因此，这些using语句不会增加您的应用程序内存，因为不会为其生成任何代码或数据。

Using在编译时仅用于将短类型名称解析为标准类型名称的目的。因此，不必要的唯一负面影响using就是稍微降低了编译时间并在编译过程中占用了更多的内存。我不会担心的。

因此，using不需要的语句的唯一真正的负面影响是对智能感知，因为键入时需要完成的潜在匹配项列表会增加。

如果像命名空间中的（未使用的）类那样调用类，则名称可能会冲突。对于System.Text，如果定义一个名为“ Encoder”的类，则会遇到问题。

无论如何，这通常是一个小问题，并且由编译器检测到。

您的应用程序将不使用更多的内存。它供编译器查找您在代码文件中使用的类。除了不干净外，它真的没有任何伤害。

主要是个人喜好。我自己清理它们（Resharper很好地告诉我什么时候不需要使用语句）。

可以说这可能会减少编译时间，但是如今，随着计算机和编译器速度的提高，它不会产生任何明显的影响。

留下额外的using指令就可以了。删除它们有一点价值，但没有太大价值。例如，它使我的IntelliSense完成列表更短，因此更易于浏览。

编译的程序集不受无关using指令的影响。

有时我将它们放在内#region，然后将其折叠；这使得查看文件更加整洁。IMO，这是的少数几种好用法之一#region。

如果要保持代码干净，using应从文件中删除未使用的语句。当您在需要理解代码的协作团队中工作，认为必须维护所有代码，更少的代码=更少的工作，带来的好处是长期的，那么好处就非常明显了。

它们只是用作快捷方式。例如，如果没有使用System，则每次都必须编写：System.Int32；在上面。

删除未使用的代码只会使您的代码看起来更干净。

using语句只是使您无法限定使用的类型。我个人喜欢清理它们。确实取决于位置指标的使用方式

仅使用实际使用的名称空间可以使代码保持记录。

您可以通过任何搜索工具轻松地找到代码的哪些部分正在相互调用。

如果您有未使用的名称空间，则在运行搜索时没有任何意义。

我现在正在清理名称空间，因为我一直被问到应用程序的哪些部分正在以一种或另一种方式访问​​相同的数据。

我知道哪些部分正在以每种方式访问​​数据，这是因为数据访问被名称空间分隔开了，例如直接通过数据库和间接通过Web服务。

我想不出一种更简单的方式一次完成所有操作。

如果您只是想让代码成为黑匣子（对开发人员而言），那么没关系。但是，如果您需要长期维护它，那么它就像所有其他代码一样是有价值的文档。

“ using”语句不会影响性能，因为它只是限定标识符名称的辅助工具。因此，如果您必须使用System.IO，则无需键入System.IO.Path.Combine（...），而只需键入Path.Combine（...）。

不要忘记，编译器在构建项目时做了很多工作来优化所有内容。使用它在很多地方都使用过，或者一旦编译就不应做1。