多余的限定符有什么缺点吗？ 有什么好处吗？
例如，引用 System.Data.Datagrid 而不仅仅是 Datagrid。 请提供示例和解释。 谢谢。
For example, referencing something as System.Data.Datagrid as opposed to just Datagrid. Please provide examples and explanation. Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
好处是您不需要为您使用的所有内容添加导入，特别是如果它是您从特定命名空间使用的唯一内容，它还可以防止冲突。
当然，缺点是代码的大小会膨胀，并且使用特定限定符越多，阅读起来就越困难。
就我个人而言，我倾向于对大多数事情使用导入，除非我确定我只会使用特定名称空间中的某些内容一次或两次，因此它不会影响代码的可读性。
The benefit is that you don't need to add an import for everything you use, especially if it's the only thing you use from a particular namespace, it also prevents collisions.
The downside, of course, is that the code balloons out in size and gets harder to read the more you use specific qualifiers.
Personally I tend to use imports for most things unless I know for sure I will only be using something from a particular namespace once or twice, so it won't impact the readability of my code.
您对所引用的类型非常明确，这是一个好处。 尽管如此，在同一过程中，您放弃了代码的清晰度，这对我来说显然是一个缺点，因为我希望代码具有可读性和可理解性。 我会选择简短的版本，除非我在不同的命名空间中存在冲突，而这只能通过显式引用类来解决。除非我使用以下关键字为其创建别名：
You're being very explicit about the type you're referencing, and that is a benefit. Although, in the very same process you're giving up code clarity, which clearly is a downside in my case, as I want code to be readable and understandable. I go for the short version unless I have a conflict in different namespaces which can only be solved with the explicit referencing to classes.. Unless I make an alias for it with the keyword using:
实际上完整路径是
global::System.Data.DataGrid。 使用更合格的路径的目的是避免使用额外的 using 语句，特别是如果引入另一个 using 会导致类型解析问题。 存在更完全限定的标识符，以便您可以在需要显式时显式地显示，但如果类的名称空间清晰，那么DataGrid版本对许多人来说会更清晰。Actually the full path is
global::System.Data.DataGrid. The point of using a more qualified path is to avoid having to use additional using statements, especially if the introduction of another using will cause problems with type resolution. More fully qualified identifiers exist so that you can be explicit when you need to be explicit, but if the class's namespace is clear, then theDataGridversion is clearer to many.我通常使用最短的形式，以使代码尽可能干净和可读。 毕竟，这就是 using 指令的用途，VS 编辑器中的工具提示可以为您提供有关类型来源的即时详细信息。
我还倾向于在 COM 互操作层中使用 RCW 的命名空间标签，以在代码中显式调用这些变量（它们可能需要特别注意生命周期和集合），例如
I generally use the shortest form available in order to keep the code as clean and readable as possible. That's what using directives are for, after all, and tooltips in the VS editor give you instant detail on the provenance of a type.
I also tend to use a namespace tag for RCWs in a COM interop layer, to call out those variables explicitly in the code (they may need special attention on lifecycle and collection), eg
就性能而言，没有优点/缺点。 一切都在编译时解决，并且无论您是否使用完全限定名称，生成的 MSIL 都是相同的。
它在 .NET 世界中广泛使用的原因是自动生成的代码，例如设计器标记。 在这种情况下，最好对类名等名称进行完全限定，因为可能与代码中的其他类发生冲突。
如果您有像 ReSharper 这样的工具，它实际上会告诉您哪些完全合格的引用是不必要的（例如，通过将它们灰显），以便您可以将它们删除。 如果您经常在各种代码库之间剪切粘贴代码，则必须完全限定它们。 （话又说回来，为什么你要一直进行剪切粘贴；这是一种糟糕的代码重用形式！）
In terms of performance there is no upside/downside. Everything is resolved at compile time and the generated MSIL is identical whether you use fully-qualified names or not.
The reason why its use is prevalent in the .NET world is because of auto-generated code, such as designer markup. In that case it would be better to fully-qualify names like class names because of possible conflicts with other classes you may have in your code.
If you have a tool like ReSharper, it will actually tell you what fully-qualified references you have are unnecessary (e.g. by graying them out) so you can lop them off. If you frequently cut-paste code across your various code bases, it would be a must to fully qualify them. (then again, why would you want to do cut-paste all the time; it's a bad form of code reuse!)
我认为这并没有真正的缺点，只是可读性与实际花费的编码时间相比。 一般来说，如果您没有带有不明确对象的命名空间，我认为实际上不需要它。 另一件需要考虑的事情是使用水平。 如果您有一种使用反射的方法，并且可以输入 System.Reflection 10 次，那么这不是什么大问题，但如果您计划大量使用命名空间，那么我会建议使用 include。
I don't think there is really a downside, just readability vs actual time spent coding. In general if you don't have namespaces with ambiguous object I don't think it's really needed. Another thing to consider is level of use. If you have one method that uses reflection and you are alright with typeing System.Reflection 10 times, then it's not a big deal but if you plan on using a namespace alot then I would recommend an include.
根据您的情况，额外的限定符将生成警告（如果这就是您所说的冗余的意思）。 如果您将警告视为错误，那就是一个非常严重的缺点。
例如，我在 GCC 中就遇到过这个问题。
Depending on your situation, extra qualifiers will generate a warning (if this is what you mean by redundant). If you then treat warnings as errors, that's a pretty serious downside.
I've run into this with GCC for example.