例如,我很少需要:
using System.Text;
但默认情况下它始终存在。我假设如果您的代码包含不必要的using directives,应用程序将使用更多内存。但还有什么我应该注意的吗?
此外,如果只在一个文件中使用相同的using指令而不是大多数/所有文件,它是否有任何区别?
编辑:请注意,此问题与称为using statement的无关概念无关,旨在通过确保当对象超出范围时帮助管理资源,其IDisposable.Dispose方法叫做。请参阅Uses of "using" in C#。
答案 0 :(得分:459)
除了编码首选项之外,还有 删除未使用的使用/名称空间的几个原因:
删除未使用的命名空间的内容不会执行:
产生的组件是相同的,有或没有未使用的使用。
答案 1 :(得分:175)
程序运行时不会改变任何内容。所需的一切都按需加载。因此,即使您具有该using语句,除非您实际使用该命名空间/程序集中的类型,否则将不会加载与该语句相关的程序集。
主要是为了清理个人偏好。
答案 2 :(得分:36)
代码清洁度 非常重要。
当人们看到多余的使用时,人们开始感觉到代码可能没有维护并且在眉地路径上。从本质上讲,当我看到一些未使用的使用声明时,脑后会出现一个小黄旗,告诉我“谨慎行事”。阅读生产代码永远不应该给你那种感觉。
清理你的用途。不要马虎。激发信心。让你的代码漂亮。给另一个开发者带来温暖模糊的感觉。
答案 3 :(得分:30)
没有与using
对应的IL构造。因此,using
语句不会增加应用程序内存,因为没有为其生成的代码或数据。
Using
仅在编译时用于将短类型名称解析为完全限定类型名称。因此,不必要的using
可能产生的唯一负面影响是在编译期间稍微减慢编译时间并占用更多内存。我不会担心这个。
因此,您不需要using
语句的唯一真正负面影响是智能感知,因为在您输入时可能完成的匹配列表会增加。
答案 4 :(得分:4)
如果您像调用名称空间中的(未使用的)类一样调用类,则可能会发生名称冲突。对于System.Text,如果定义名为“Encoder”的类,则会出现问题。
无论如何,这通常是一个小问题,并由编译器检测到。
答案 5 :(得分:2)
您的应用程序不会使用更多内存。它用于编译器查找您在代码文件中使用的类。除了不干净之外,它真的没什么坏处。
答案 6 :(得分:2)
主要是个人偏好。我自己清理它们(Resharper很好地告诉我什么时候不需要使用语句)。
可以说它可能会缩短编译时间,但是如今计算机和编译器的速度不会产生任何可察觉的影响。
答案 7 :(得分:2)
留下额外的using
指令很好。删除它们有一点价值,但并不多。例如,它使我的IntelliSense完成列表更短,因此更容易导航。
编译的程序集不受无关的using
指令的影响。
有时候我把它们放在#region
里面,让它崩溃;这使查看文件更清洁。 IMO,这是#region
的少数好用之一。
答案 8 :(得分:2)
如果要保持代码清洁,则应从文件中删除未使用的using
语句。当您在一个需要理解您的代码的协作团队中工作,认为您的所有代码都必须得到维护,代码减少或工作量减少,这些好处是长期的。
答案 9 :(得分:1)
它们仅用作快捷方式。例如,你必须写: System.Int32每次如果你没有使用系统;在顶部。
删除未使用的代码只会让您的代码看起来更清晰。
答案 10 :(得分:1)
using语句只是让您无法限定您使用的类型。我个人喜欢清理它们。实际上,这取决于如何使用loc指标
答案 11 :(得分:1)
只有您实际使用的命名空间允许您记录您的代码。
您可以通过任何搜索工具轻松找到代码的哪些部分相互调用。
如果您有未使用的命名空间,则在运行搜索时没有任何意义。
我正在努力清理名称空间,因为我经常被问到应用程序的哪些部分以这种或那种方式访问相同的数据。
我知道哪些部分正在以各种方式访问数据,因为数据访问由命名空间分隔,例如直接通过数据库并直接通过Web服务。
我想不出一个简单的方法可以同时做到这一点。
如果你只想让你的代码成为一个黑盒子(对开发者来说),那么是的并不重要。但是如果你需要长期维护它,它就像所有其他代码一样是有价值的文档。
答案 12 :(得分:0)
'using'语句不会影响性能,因为它只是限定标识符名称的助手。因此,您无需键入 System.IO.Path.Combine(...),只需输入 Path.Combine(...)即可使用System.IO 。
答案 13 :(得分:0)
不要忘记编译器在构建项目时需要做很多工作来优化所有内容。使用它在很多地方使用,或者1编译后不应该做不同的。