例如,我很少需要:
using System.Text;
但它总是默认存在的。如果代码中包含不必要的using指令,我假设应用程序将使用更多内存。但是还有什么我应该注意的吗?
同样,如果同一个using指令只在一个文件中使用,而在大多数/所有文件中使用,会有任何区别吗?
编辑:请注意,这个问题不是关于不相关的概念,称为using语句,旨在帮助管理资源,确保当一个对象超出作用域时,它的IDisposable。方法被调用。参见c#中“using”的用法。
例如,我很少需要:
using System.Text;
但它总是默认存在的。如果代码中包含不必要的using指令,我假设应用程序将使用更多内存。但是还有什么我应该注意的吗?
同样,如果同一个using指令只在一个文件中使用,而在大多数/所有文件中使用,会有任何区别吗?
编辑:请注意,这个问题不是关于不相关的概念,称为using语句,旨在帮助管理资源,确保当一个对象超出作用域时,它的IDisposable。方法被调用。参见c#中“using”的用法。
当前回答
不要忘记编译器在构建项目时做了很多工作来优化所有内容。使用that在很多地方都被使用,或者1在编译后不应该做不同的事情。
其他回答
只使用实际使用的名称空间可以使代码保持文档化。
您可以通过任何搜索工具轻松地找到代码的哪些部分相互调用。
如果您有未使用的名称空间,这在运行搜索时没有任何意义。
我现在正在清理名称空间,因为经常有人问我应用程序的哪些部分正在以某种方式访问相同的数据。
我知道哪些部分以不同的方式访问数据,因为数据访问被名称空间分开,例如直接通过数据库和间接通过web服务。
我想不出比这更简单的方法了。
如果你只是想让你的代码成为一个黑盒(对开发人员来说),那么没关系。但是如果您需要长期维护它,那么它就像所有其他代码一样是有价值的文档。
using语句不会影响性能,因为它只是限定标识符名称的一个助手。因此,如果你使用System.IO,你不必输入System.IO.Path.Combine(…),你可以简单地输入Path.Combine(…)。
您的应用程序将不会使用更多内存。它是为了让编译器找到你在代码文件中使用的类。除了不干净,真的没什么伤害。
代码整洁是很重要的。
当看到多余的使用时,人们开始觉得代码可能没有得到维护,并处于布劳菲尔德路径上。从本质上讲,当我看到一些没有用过的using语句时,我的大脑后部就会升起一面小黄旗,告诉我“谨慎行事”。而阅读产品代码绝不会让你有这种感觉。
所以清理你的使用。不要马虎。激发人们的信心。让你的代码更漂亮。给其他开发者温暖的感觉。
如果您像名称空间中的(未使用的)类那样调用类,则可能会发生名称冲突。在系统的情况下。文本,如果定义了一个名为“Encoder”的类,就会遇到问题。
无论如何,这通常是一个小问题,并由编译器检测。