为什么要删除不必要的 C# using 指令?
例如,我很少需要:
using System.Text;
但默认情况下它总是存在。 我认为如果您的代码包含不必要的 使用,应用程序将使用更多内存指令。 但还有什么我应该注意的吗?
另外,如果仅在一个文件中使用相同的 using 指令与在大多数/所有文件中使用相同的 using 指令,这有什么区别吗?
编辑:请注意,这个问题与称为 using 语句的不相关概念无关,旨在帮助人们管理资源,确保当对象超出范围时,其IDisposable.Dispose 方法被调用。 请参阅C# 中“using”的用法。
For example, I rarely need:
using System.Text;
but it's always there by default. I assume the application will use more memory if your code contains unnecessary using directives. But is there anything else I should be aware of?
Also, does it make any difference whatsoever if the same using directive is used in only one file vs. most/all files?
Edit: Note that this question is not about the unrelated concept called a using statement, designed to help one manage resources by ensuring that when an object goes out of scope, its IDisposable.Dispose method is called. See Uses of "using" in C#.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(14)
如果您像命名空间中的(未使用的)类一样调用您的类,则可能会发生名称冲突。 对于 System.Text,如果定义一个名为“Encoder”的类,就会遇到问题。
无论如何,这通常是一个小问题,并由编译器检测到。
You may have name clashes if you call your classes like the (unused) classes in the namespace. In the case of System.Text, you'll have a problem if you define a class named "Encoder".
Anyways this is usually a minor problem, and detected by the compiler.
没有与
using
对应的 IL 构造。 因此,using
语句不会增加应用程序内存,因为没有为其生成代码或数据。Using
在编译时仅用于将短类型名称解析为完全限定类型名称。 因此,不必要的using
唯一的负面影响是稍微减慢编译时间并在编译期间占用更多内存。 不过我不会担心这一点。因此,拥有不需要的
using
语句的唯一真正的负面影响是对智能感知的影响,因为您键入时完成的潜在匹配列表会增加。There's no IL construct that corresponds to
using
. Thus, theusing
statements do not increase your application memory, as there is no code or data that is generated for it.Using
is used at compile time only for the purposes of resolving short type names to fully qualified type names. Thus, the only negative effect unnecessaryusing
can have is slowing the compile time a little bit and taking a bit more memory during compilation. I wouldn't be worried about that though.Thus, the only real negative effect of having
using
statements you don't need is on intellisense, as the list of potential matches for completion while you type increases.除了编码偏好之外,删除未使用的 using(s)/命名空间的原因很少:
删除未使用的命名空间不会 do:
无论是否删除未使用的使用,所得组件都是相同的。
There are few reasons for removing unused using(s)/namespaces, besides coding preference:
What removing the unused namespaces won't do:
The resulting assembly is the same with or without unused using(s) removed.
当你的程序运行时它不会改变任何东西。 所需的一切都是按需加载的。 因此,即使您有该 using 语句,除非您实际使用该命名空间/程序集中的类型,否则不会加载与 using 语句相关的程序集。
主要是为了个人喜好而清理。
It won't change anything when your program runs. Everything that's needed is loaded on demand. So even if you have that using statement, unless you actually use a type in that namespace / assembly, the assembly that using statement is correlated to won't be loaded.
Mainly, it's just to clean up for personal preference.
代码整洁度很重要。
当人们看到多余的使用时,人们就会开始感觉到代码可能没有维护并且处于浏览路径上。 本质上,当我看到一些未使用的 using 语句时,我的大脑后面会升起一个小黄旗,告诉我“谨慎行事”。 阅读生产代码永远不会给你这种感觉。
所以清理你的使用。 不要马虎。 激发信心。 让你的代码变得漂亮。 给另一个开发人员一种温暖模糊的感觉。
Code cleanliness is important.
One starts to get the feeling that the code may be unmaintained and on the browfield path when one sees superfluous usings. In essence, when I see some unused using statements, a little yellow flag goes up in the back of my brain telling me to "proceed with caution." And reading production code should never give you that feeling.
So clean up your usings. Don't be sloppy. Inspire confidence. Make your code pretty. Give another dev that warm-fuzzy feeling.
如果您想保持代码干净,则应从文件中删除未使用的
using
语句。 当您在需要理解代码的协作团队中工作时,好处就显得非常明显,认为必须维护所有代码,更少的代码=更少的工作,好处是长期的。if you want to maintain your code clean, not used
using
statements should be removed from the file. the benefits appears very clear when you work in a collaborative team that need to understand your code, think all your code must be maintained, less code = less work, the benefits are long term.您的应用程序不会使用更多内存。 它是为了让编译器找到您在代码文件中使用的类。 除了不干净之外,确实没有什么坏处。
Your application will not use more memory. It's for the compiler to find classes you use in the code files. It really doesn't hurt beyond not being clean.
留下额外的
using
指令就可以了。 删除它们有一点价值,但价值不大。 例如,它使我的 IntelliSense 完成列表更短,因此更易于导航。已编译的程序集不受无关的
using
指令的影响。有时我将它们放在
#region
中,然后将其折叠起来; 这使得查看文件变得更加清晰。 IMO,这是#region
为数不多的好用途之一。Leaving extra
using
directives is fine. There is a little value in removing them, but not much. For example, it makes my IntelliSense completion lists shorter, and therefore easier to navigate.The compiled assemblies are not affected by extraneous
using
directives.Sometimes I put them inside a
#region
, and leave it collapsed; this makes viewing the file a little cleaner. IMO, this is one of the few good uses of#region
.主要是个人喜好。 我自己清理它们(ReSharper 很好地告诉我何时有不需要的 using 语句)。
人们可能会说它可能会减少编译时间,但随着当今计算机和编译器速度的提高,它不会产生任何明显的影响。
It’s personal preference mainly. I clean them up myself (ReSharper does a good job of telling me when there’s unneeded using statements).
One could say that it might decrease the time to compile, but with computer and compiler speeds these days, it just wouldn’t make any perceptible impact.
它们只是用作快捷方式。 例如,你必须写:
如果您没有正在使用的系统,则每次都会使用 System.Int32; 在上面。
删除未使用的只会让您的代码看起来更干净。
They are just used as a shortcut. For example, you'd have to write:
System.Int32 each time if you did not have a using System; on top.
Removing unused ones just makes your code look cleaner.
using 语句只是让您无法限定所使用的类型。 我个人喜欢清理它们。 实际上这取决于 loc 指标的使用方式
The using statement just keeps you from qualifying the types you use. I personally like to clean them up. Really it depends on how a loc metric is used
仅拥有您实际使用的命名空间可以让您记录代码。
您可以通过任何搜索工具轻松找到代码的哪些部分正在相互调用。
如果您有未使用的命名空间,那么在运行搜索时这没有任何意义。
我现在正在努力清理命名空间,因为我经常被问到应用程序的哪些部分正在以某种方式访问相同的数据。
我知道哪些部分正在以各种方式访问数据,因为数据访问被命名空间分开,例如直接通过数据库和间接通过 Web 服务。
我想不出更简单的方法来一次完成这一切。
如果您只是希望您的代码成为一个黑匣子(对于开发人员而言),那么是的,这并不重要。 但是,如果您需要随着时间的推移对其进行维护,那么它就像所有其他代码一样是有价值的文档。
Having only the namespaces that you actually use allows you to keep your code documented.
You can easily find what parts of your code are calling one another by any search tool.
If you have unused namespaces this means nothing, when running a search.
I'm working on cleaning up namespaces now, because I'm constantly asked what parts of the application are accessing the same data one way or another.
I know which parts are accessing data each way due to the data access being separated by namespaces e.g. directly through a database and in-directly through a web service.
I can't think of a simpler way to do this all at once.
If you just want your code to be a black box (to the developers), then yes it doesn't matter. But if you need to maintain it over time it is valuable documentation like all other code.
“using”语句不会影响性能,因为它只是限定标识符名称的助手。 因此,您不必输入 System.IO.Path.Combine(...),而只需输入 Path.Combine(...)(如果您有) 使用 System.IO。
The 'using' statement does not affect performance as it is merely a helper in qualifying the names of your identifiers. So instead of having to type, System.IO.Path.Combine(...), you can simply type, Path.Combine(...) if you have using System.IO.
不要忘记,编译器在构建项目时会做很多工作来优化所有内容。 使用它在很多地方使用,或者 1 一旦编译就不应该做不同的事情。
Do not forget that the compiler do a lot of work to optimize everything when building your project. Using that is used in a lot of place or 1 shouldn't do a different once compiled.