冗余限定符有啥缺点吗？有啥好处吗？

Posted 2023-03-29

【中文标题】冗余限定符有啥缺点吗？有啥好处吗？

【英文标题】：Is there any downside to redundant qualifiers? Any benefit?冗余限定符有什么缺点吗？有什么好处吗？

【发布时间】：2010-09-11 02:07:13

【问题描述】：

例如，引用 System.Data.Datagrid 而不仅仅是 Datagrid。请提供例子和解释。谢谢。

【参考方案1】：

好处是您不需要为您使用的所有内容添加导入，特别是如果它是您从特定命名空间使用的唯一内容，它还可以防止冲突。

当然，不利的一面是代码会膨胀，并且越是使用特定的限定符就越难阅读。

我个人倾向于对大多数事情使用导入，除非我确定我只会使用来自特定命名空间的东西一次或两次，因此它不会影响我的代码的可读性。

【讨论】：

你真的认为添加 1 using 语句相对于必须输入完全限定名称是不利的吗？

@Statement 当你有 20、30、40 个 using 语句时，是的，这是一个缺点。

好吧，问题是，如果您不使用语句执行 20-40 次，您将不得不输入 FQN 20-40 次。我坚信（使用）使用语句是一件好事的学校。但这确实是个人喜好，不是吗。

【参考方案2】：

您对所引用的类型非常明确，这是一个好处。虽然，在同一个过程中，您放弃了代码清晰度，这在我的情况下显然是一个缺点，因为我希望代码具有可读性和可理解性。我会选择简短的版本，除非我在不同的命名空间中有冲突，这只能通过显式引用类来解决。除非我使用关键字为它创建别名：

using Datagrid = System.Data.Datagrid;

【讨论】：

是的，我想我不需要显式声明，因为我可以将鼠标悬停在项目上并看到完全限定的名称，这要归功于 VS 方便的工具提示（和 Eclipse 等）。

【参考方案3】：

其实完整路径是global::System.Data.DataGrid。使用更合格的路径的目的是避免使用额外的 using 语句，特别是如果引入另一个 using 将导致类型解析问题。存在更多完全限定的标识符，以便在需要显式时可以显式，但如果类的命名空间清晰，那么DataGrid 版本对许多人来说更清晰。

【参考方案4】：

我通常使用可用的最短格式，以使代码尽可能简洁易读。毕竟，这就是 using 指令的用途，VS 编辑器中的工具提示可让您即时详细了解类型的出处。

我也倾向于在 COM 互操作层中为 RCW 使用命名空间标签，以在代码中显式调用这些变量（它们可能需要特别注意生命周期和集合），例如

using _Interop = Some.Interop.Namespace;

【参考方案5】：

在性能方面没有优势/劣势。一切都在编译时解决，无论您是否使用完全限定名称，生成的 MSIL 都是相同的。

它在 .NET 世界中广泛使用的原因是因为自动生成的代码，例如设计器标记。在这种情况下，最好使用完全限定名称（如类名），因为可能与代码中可能存在的其他类发生冲突。

如果您有 ReSharper 之类的工具，它实际上会告诉您哪些完全限定的引用是不必要的（例如，通过将它们变灰），因此您可以删除它们。如果您经常在各种代码库中剪切粘贴代码，则必须完全限定它们。 （再说一遍，你为什么要一直做剪切粘贴；这是一种不好的代码重用形式！）

【参考方案6】：

我认为没有真正的缺点，只是可读性与实际花费的编码时间相比。一般来说，如果你没有带有模糊对象的命名空间，我认为它不是真的需要。要考虑的另一件事是使用水平。如果您有一种使用反射的方法，并且您可以输入 System.Reflection 10 次，那么这没什么大不了的，但是如果您打算大量使用命名空间，那么我会推荐一个包含。

【讨论】：

那个，我做任何 ReSharper 告诉我做的事情。我只是半开玩笑。

LOL =P 那么 ReSharper 是一个非常漂亮的插件，很多人都喜欢它，所以我不会忽视它的建议。

【参考方案7】：

根据您的情况，额外的限定符会产生警告（如果这就是您所说的冗余）。如果您随后将警告视为错误，那将是一个非常严重的缺点。

例如，我在 GCC 中遇到过这种情况。

struct A 
    int A::b; // warning!

【讨论】：

哦，不错的场景。我想我没有遇到过这种情况。