在 VB.NET 中使用 Dim foo As Foo 有问题吗？答案

【问题标题】：Are there issues using Dim foo As Foo in VB.NET?在 VB.NET 中使用 Dim foo As Foo 有问题吗？
【发布时间】：2009-08-28 15:01:21
【问题描述】：

在最近的一个 VB.NET 项目中，我采用了我在 C# 中习惯使用的命名约定。即，经常调用与其引用的类同名的变量，只是大小写不同，例如

Foo foo = new Foo(); // C#

Dim foo As New Foo() ' VB.NET

我发现这通常是最清晰的代码编写方式，尤其是对于小方法。这种编码风格在 C# 中显然可以正常工作，区分大小写，并且由于 Visual Studio 提供的语法高亮显示，很容易看出类名和变量名不同。

但是，令我惊讶的是，这在 VB.NET 中几乎 100% 的时间* 都可以正常工作。唯一的问题是变量名似乎具有多重身份。也就是说，它可以用于调用 Foo 类的实例方法和共享（静态）方法。但这并没有真正引起任何问题，它只是意味着 Intellisense 会在您点击“。”后提供一个包含静态方法和实例方法的列表。在变量名之后。

再次令我惊讶的是，这实际上并没有导致我的项目出现任何混乱，而且到目前为止它非常成功！然而，我是唯一参与这个特定项目的人。

这是一个稍长的例子：

Dim collection as Collection = New Collection()
For Each bar As Bar in Bar.All()
    collection.SomeInstanceMethod(bar)
Next
collection.SomeSharedMethod()

* 我发现的唯一问题是，有时“重命名”重构工具会混淆，即在重命名类时，它也会在声明行中重命名与类同名的变量 (@987654324 @)，但不是对该变量的其他引用，导致编译器问题（duh）。不过，这些总是很容易纠正。

另一个小烦恼是 VB.NET 语法高亮显示类名与变量名没有任何不同，这使得它不如在 C# 中使用它时那么好。我仍然发现代码非常可读。

有没有其他人尝试在团队环境中允许这样做？ VB.NET 中的这种命名约定是否还有其他潜在问题？

【问题讨论】：

这就是我不喜欢 VB.NET 的原因之一：在 C# 中 Foo 和 foo 显然是不同的标识符，在 VB 中它会变得混乱......
这是我不喜欢 C# 的原因之一。 Thomas Levesque 和 THOMAS LEVESQUE 和 thomas levesque 是不同的人吗？
不，但幸运的是，C# 代码并不打算直接放在电话簿中。
@Kyralessa：好点；）。我想这只是个人喜好问题......
好吧，感谢大家对此的贡献，我对在 VB.NET 中使用这种命名约定的利弊（主要是弊端）有了更多的了解......我'我在下面的摘要回答中发布了指向 Microsoft 主要文章的链接：stackoverflow.com/questions/1347569/… 我很想知道是否有人认为他们知道编写漂亮的 VB.NET 变量名称的一种真正方法。祝大家好运

标签： c# vb.net coding-style case-sensitive case-insensitive

【解决方案1】：

尽管 VB 不区分大小写，但编译器足够智能，不会混淆对象实例和类。

但是，在不区分大小写的语言中使用相同的名称肯定是非常危险和错误的！特别是如果其他程序员正在从事该项目。

【讨论】：

这样一种危险是，如果“foo”的声明消失（被注释掉，或者甚至只是剪切粘贴），那么编译器将更改分辨率以指向类型，本质上获取预期的Dim foo as new Foo() 并将其转换为Dim Foo as New Foo()。保持清洁很痛苦！
是的，我觉得它可能会让一些人感到困惑，但既然编译器处理得如此稳定和确定，真的那么糟糕吗？如果编译器有可能导致意外行为和/或此类 VB.NET 代码到 IL 的转换是未定义的，我可能至少会发出警告，如果没有抛出一个真正的错误。
Sam，正如许多计算机科学教师所说，仅仅因为你能做到这一点并不意味着你必须这样做。虽然编译器没有抱怨，但这是一种不好的做法，应该避免。
说它非常危险是完全错误的。 Moayad，你对 Sam 的回应是这很糟糕，因为这是一种糟糕的做法。这不是我所说的争论;-)
Meta-Knight，我同意，这不是一个很好的回应 :) Sam，您可以参考：Cwalina、Krzysztof 和 Brad Abrams。框架设计指南：可重用 .NET 库的约定、惯用语和模式。马萨诸塞州波士顿：Addison-Wesley Professional，2005 年。

【解决方案2】：

我必须在 VB 和 C# 之间来回切换，我们认为这种做法很糟糕。我们也不喜欢让 C# 中的变量名称与它们的类型仅按大小写不同。相反，我们使用 _ 前缀或给它一个更有意义的名称。

每当您开始一门新语言时，不可避免地会注意到一堆不同的东西，并怀念旧的做事方式。这通常是因为您最初没有意识到另一种语言的不同功能可以解决相同的问题。由于您是 VB 新手，因此这里有一些说明可以帮助您完成工作：

说 VB.Net 不区分大小写并不是 100% 正确的，除非您还指出它区分大小写。当您声明 ~~variable~~ 标识符时，IDE 将记录您使用的大小写并自动更正其他使用以匹配该大小写。您可以使用此功能来帮助发现错别字或 IDE 可能对变量或类型感到困惑的地方。我实际上已经开始更喜欢这个而不是真正的区分大小写的方案。

VB.Net 以不同的方式导入命名空间。如果你想使用File类，你可以直接说IO.File而不需要在顶部导入System.IO。该功能在学习具有几个嵌套命名空间层的新 API 时特别方便，因为您可以导入 API 的顶级部分，键入下一个命名空间名称，系统会提示您该命名空间中的类列表.这里很难解释，但是如果你找到它并开始使用它，当你回到 C# 时，你真的会怀念它。主要的是，至少对我而言，它确实打破了我的流程，需要跳转到文件顶部以添加另一个 using 指令用于命名空间，我可能只使用一次或两次。在 VB 中，这种中断并不常见。

VB.Net 做后台编译。当您的光标离开一行时，您知道该行是否编译。这在一定程度上弥补了不突出显示类名的原因，因为这在 C# 中有用的部分原因是您知道您输入了正确的类型。 VB.Net 让您在这方面更有信心。

【讨论】：

有趣的笔记，谢谢。在使用 VB.NET 时，我注意到命名空间的嵌套（并对此感到震惊），尽管我认为你的观点对初学者或那些永远不会费心学习更简洁的语言（如 C#）的人有好处。顺便说一句，只要你有适当的引用，你只需键入一个类名并点击“Ctrl+Space”即可在 C# 中自动插入using Namespace 声明。

【解决方案3】：

我将与此处的其他答案有所不同...我认为这样做没有任何问题。我经常这样做，并且因此产生的问题绝对为零。

如果你使用小写的变量名，你可以很容易的区分变量和类型，编译器不会混淆这两个标识符。

如果你删除变量声明，编译器会认为其他对该变量的引用现在引用了该类型，但这并不是真正的问题，因为这些将被标记为错误。

【讨论】：

是的，我不是唯一一个不认为这很糟糕的人！ :) 关于删除变量声明也很好，你是对的，没有理由混淆，因为你不能有一个与实例成员具有相同签名的静态（共享）成员，所以编译器不可能在这个问题上感到困惑。 Intellisense 甚至不会感到困惑……我认为这必须说明什么。

【解决方案4】：

我过去也做过同样的事情。我开始远离它，因为 Visual Studio 在自动格式化代码并将我的静态方法调用的大小写更改为小写时偶尔会感到困惑。这比不能仅按大小写区分变量和类名更令人讨厌。但是，纯粹从技术角度来看，它不应该引起任何问题。

【讨论】：

嗯，这还没有发生在我身上，但认为这可能是不使用这些名称的最有说服力的理由！您使用的是哪个版本的 Visual Studio？我只用过2008
VS 2008。它不会一直发生。

【解决方案5】：

正如 Moayad 所指出的，编译器可以分辨出其中的差异——但这是一种不好的做法，可能会导致维护问题和其他副作用。

更好的做法是尝试在变量使用的上下文中命名变量，而不仅仅是类型名称。这导致了自记录代码并且需要更少的 cmets（cmets 被广泛滥用为编写密集代码的借口）。

【讨论】：

是的，当涉及到更长的方法时，我绝对同意，但是对于非常小的实用程序方法，通常没有其他关于调用函数的上下文可以提供更具描述性的名称。
如果我有足够的声望，我会投票给你，不过我需要 15 个 :(

【解决方案6】：

只要编译器总能分辨出Foo 是指类还是变量，它才是安全的，最终你会遇到它不能分辨的情况。 Eric Lippert 讨论了可能出错的事情on his blog。

【讨论】：

【解决方案7】：

我一直都在使用这个约定，而且从来都不是问题。变量最自然的名称通常是类名，因此您应该这样称呼它（任意行的最佳名称？行。）。

唯一的缺点是某些工具会错误地解释上下文。例如，Visual Studio 2010 beta 1 有时会在与类同名的变量上使用类高亮。这有点烦人。

上下文敏感性比区分大小写更接近我的想法。

【讨论】：

酷，所以 VS 2010 会比 VS 2008 为 VB 做更多的语法高亮？我认为有了这个补充，可能绝对没有理由不使用这个约定……顺便说一句，你最后一句话是什么意思？
是的，它以浅蓝色突出显示类。最后一句话意味着我更喜欢上下文相关语言而不是区分大小写的语言。

【解决方案8】：

嗯，这不是最终的答案，我也不认为有一个确定的答案，但普遍的看法似乎是使用这种命名约定不是一个好主意！不过，必须有一种真正的方法来编写漂亮的 VB.NET 变量名，而且我不喜欢任何替代方法......

这里是微软官方指南的链接，供感兴趣的人使用，尽管它们似乎没有涵盖这个特定问题（如果我错过了，请纠正我）。

Visual Basic 命名约定：http://msdn.microsoft.com/en-us/library/0b283bse.aspx

声明的元素名称：http://msdn.microsoft.com/en-us/library/81ed9a62.aspx

大家干杯！

【讨论】：

【解决方案9】：

VB.NET 不区分大小写！这相当于：

Foo Foo = new Foo(); // C#

作为我们团队环境中的标准，我们将使用：

Dim oFoo as New Foo 'VB.NET

【讨论】：

是的，但你不会写它；）
不适用于局部变量，但属性与其类型同名是很常见的。请参阅 Eric Lippert 的这篇文章：blogs.msdn.com/ericlippert/archive/2009/07/06/color-color.aspx
@Thomas: 是的，但 VB.NET 商店会尽量避免这种情况，因为他们控制的组件正是出于这个原因。使用 3rd 方程序集时问题不大，但在编写具有这些命名冲突的程序集时主要是个问题