在 VB.NET 中使用 Dim foo As Foo 是否存在问题？
在最近的 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()
* 我发现的唯一问题是有时“重命名”重构工具会感到困惑，即在重命名类时，它也会在声明中重命名与类同名的变量行（Dim foo As...），但不是对该变量的其他引用，导致编译器问题（废话）。不过，这些总是很容易纠正。
另一个小烦恼是 VB.NET 语法高亮显示的类名与变量名没有任何不同，这使得它不如在 C# 中使用时那么好。但我仍然发现代码非常可读。
有没有其他人尝试在团队环境中允许这样做？ VB.NET 中的此命名约定是否存在其他潜在问题？
In a recent VB.NET project I adopted the naming conventions I'm used to using in C#. Namely, often calling a variable the same name as the class it references, only with a different case, e.g.
Foo foo = new Foo(); // C#
Dim foo As New Foo() ' VB.NET
I find this is often the clearest way to write code, especially for small methods. This coding style obviously works fine in C#, being case sensitive, and because of the syntax highlighting provided by Visual Studio, it is very easy to see that the class name and the variable name are different.
However, to my surprise, this also worked fine nearly 100% of the time* in VB.NET. The only issue was that the variable name then appeared to take on a multiple identity. Namely it could be used to call both instance methods and Shared (static) methods of the Foo class. This didn't really cause any problems though, it just meant that Intellisense would provide a list containing both static and instance methods after you hit the '.' after the variable name.
I found, again to my surprise, that this didn't actually lead to any confusion in my project, and it's been very successful so far! However I was the only person working on this particular project.
Here is a slightly longer example:
Dim collection as Collection = New Collection()
For Each bar As Bar in Bar.All()
collection.SomeInstanceMethod(bar)
Next
collection.SomeSharedMethod()
* The only issue I found with this was that sometimes the 'Rename' refactoring tool got confused, i.e. when renaming a class it would rename the variables with the same name as the class as well, in their declaration lines (Dim foo As...), but not the other references to that variable, causing compiler issues (duh). These were always easy to correct though.
Another small annoyance is that the VB.NET syntax highlighter doesn't highlight class names any differently than variable names, making it not quite as nice as when using it in C#. I still found the code very readable though.
Has anyone else tried allowing this in a team environment? Are there any other potential issues with this naming convention in VB.NET?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
尽管 VB 不区分大小写，但编译器足够智能，不会混淆对象实例和类。
然而，在不区分大小写的语言中使用相同的名称肯定是非常危险和错误的！特别是当其他程序员正在从事该项目时。
Although VB is case-insensitive, the compiler is intelligent enough to not being confused between the object-instance and the class.
However, it's certainly very dangerous and wrong to use the same name in a case-insensitive language! Especially if other programmers are working on that project.
我必须在 VB 和 C# 之间来回切换，我们认为这种做法很糟糕。我们也不喜欢让 C# 中的变量名仅在大小写上与其类型不同。相反，我们使用 _ 前缀或给它一个更有意义的名称。
每当你开始使用一种新语言时，你都不可避免地会注意到一些不同的事情，并且怀念旧的做事方式。通常这是因为您最初没有意识到其他语言中可以解决相同问题的不同功能。由于您是 VB 新手，这里有一些注释可以帮助您完成工作：
说 VB.Net 不区分大小写并不是 100% 正确，除非您也指出它是大小写的 -意识到。。当您声明
变量标识符时，IDE 将记录您使用的大小写，并自动更正其他用途以匹配该大小写。您可以使用此功能来帮助发现拼写错误或 IDE 可能对变量或类型感到困惑的地方。实际上，与真正的区分大小写的方案相比，我更喜欢这种方案。VB.Net 以不同的方式导入名称空间。如果你想使用
File类，你可以直接输入IO.File，而不需要在顶部导入System.IO。在学习具有几个嵌套命名空间层的新 API 时，该功能特别有用，因为您可以导入 API 的顶级部分，输入下一个命名空间名称，然后系统会提示您该命名空间中的类列表。这里很难解释，但是如果你寻找它并开始使用它，当你回到 C# 时你真的会想念它。最重要的是，至少对我来说，它确实打破了我的流程，需要跳转到文件顶部为我可能只使用一次或两次的命名空间添加另一个 using 指令。在 VB 中，这种中断不太常见。VB.Net 进行后台编译。当您的光标离开一行时，您知道该行是否可以编译。这在某种程度上弥补了不突出显示类名的问题，因为它在 C# 中有用的部分原因是让您知道您输入的类型是正确的。 VB.Net 在这方面让您更有信心。
I have to move back and forth between VB and C#, and we consider this poor practice. We also don't like letting variable names in C# differ from their type only by case. Instead, we use an _ prefix or give it a more meaningful name.
Whenever you start a new language it's inevitable you'll notice a bunch of things that are different and miss the old way of doing things. Often this is because you are initially unaware of different features in the other language has that address the same problem. Since you're new to VB, here are a couple notes that will help you get things done:
It's not 100% correct to say that VB.Net is case-insensitive unless you also make the point that it is case-aware. When you declare an
variableidentifier, the IDE will take note of what case you used and auto-correct other uses to match that case. You can use this feature to help spot typos or places where the IDE might be confused about a variable or type. I've actually come to prefer this to real case-sensitive schemes.VB.Net imports namespaces differently. If you want to use the
Fileclass, you can just sayIO.Filewithout needing to importSystem.IOat the top. The feature especially comes in handy when learning a new API with a few nested namespace layers, because you can import a top-level section of API, type the next namespace name, and you'll be prompted with a list of classes in that namespace. It's hard to explain here, but if you look for it and start using it, you'll really miss it when going back to C#. The main thing is that, for me at least, it really breaks my flow to need to jump to the top of the file to add yet another using directive for a namespace I may only use once or twice. In VB, that interruption is much less common.VB.Net does background compilation. The moment your cursor leaves a line, you know whether or not that line compiles. This somewhat makes up for not highlighting class names, because part of why that's useful in C# is so you know that you typed it correctly. VB.Net gives you even more confidence in this regard.
我将与这里的其他答案不同......我认为这样做没有任何问题。我经常这样做，并且由此产生的问题绝对为零。
如果使用小写字母作为变量名，则可以轻松区分变量和类型，并且编译器不会混淆这两个标识符。
如果删除变量声明，编译器会认为对此变量的其他引用现在引用该类型，但这并不是真正的问题，因为这些引用将被标记为错误。
I'm going to differ with the rest of the answers here... I don't think there is any problem with doing this. I do it regularly, and have absolutely 0 problems resulting from it.
If you use lowercase for the variable name you can easily differentiate the variable from the type, and the compiler will not confuse the two identifiers.
If you delete the variable declaration, the compiler will think other references to this variable now refer to the type, but it's not really a problem because those will be tagged as errors.
我过去也做过同样的事情。不过，我开始放弃它，因为当 Visual Studio 自动格式化代码并将静态方法调用的大小写更改为小写时，它偶尔会感到困惑。这比无法仅按大小写区分变量名和类名更烦人。但是，纯粹从技术角度来看，它不应该引起任何问题。
I have done the same thing in the past. I'm starting to move away from it though because Visual Studio will occasionally get confused when it auto formats the code and changes the casing on my static method calls to lower case. That is even more annoying than not being able to differentiate the variable and class names by case only. But, purely from technical perspective it should not cause any issues.
正如 Moayad 指出的那样，编译器可以分辨出差异，但这是一种不好的做法，可能会导致维护问题和其他副作用。
更好的做法是尝试在变量使用的上下文中命名变量，而不仅仅是类型名称。这导致了自记录代码并且需要更少的注释（注释被严重滥用作为编写密集代码的借口）。
As Moayad notes, the compiler can tell the difference--but it's bad practice that can lead to maintenance issues and other side effects.
A better practice all-around is to try to name the variable in the context they're being used, rather than just the type name. This leads to self-documenting code and requires fewer comments (comments are greatly abused as an excuse to write dense code).
只有当编译器始终能够判断 Foo 是指类还是变量时，它才是安全的，最终您会遇到无法判断的情况。 Eric Lippert 在 上讨论了可能出错的情况他的博客。
It's only safe as long as the compiler can always tell whether
Foomeans the class or the variable, and eventually you'll hit a case where it can't. Eric Lippert discusses the sort of thing that can go wrong on his blog.我一直使用这个约定，从来没有出现过问题。变量最自然的名称通常是类名称，因此您应该这样称呼它（任意行的最佳名称？行。）。
唯一的缺点是某些工具无法正确解释上下文。例如，Visual Studio 2010 beta 1 有时会在与类同名的变量上使用类突出显示。这有点烦人。
上下文敏感性比区分大小写更接近我的想法。
I use this convention all the time, and it's never been a problem. The most natural name for a variable is often the class name, and therefore that's what you should call it (Best name for an arbitrary Line? line.).
The only downside is when some tool interprets the context incorrectly. For example, visual studio 2010 beta 1 sometimes uses the class highlight on variables named the same as the class. That's a bit annoying.
Context sensitivity is much closer to how I think than case sensitivity.
好吧，这不是最终的答案，我不认为有一个明确的答案，但普遍的观点似乎是使用这种命名约定不是一个好主意！不过，必须有一种真正的方法来编写漂亮的 VB.NET 变量名称，而且我不喜欢任何替代方法...
以下是任何感兴趣的人的官方 Microsoft 指南的链接，尽管它们似乎没有涵盖这个特定的问题（如果我错过了，请纠正我）。
Visual Basic 命名约定： http://msdn.microsoft.com/en-us /library/0b283bse.aspx
声明的元素名称：http:// msdn.microsoft.com/en-us/library/81ed9a62.aspx
干杯！
Well, this isn't the final answer, and I don't think there is a definitive one, but the general opinion seems to be that it's not a good idea to use this naming convention! There must be one true way to write nice VB.NET variable names though, and I don't like any of the alternatives...
Here are links to the official Microsoft guidelines for anyone who's interested, although they don't seem to cover this particular question (please correct me if I've missed it).
Visual Basic Naming Conventions: http://msdn.microsoft.com/en-us/library/0b283bse.aspx
Declared Element Names: http://msdn.microsoft.com/en-us/library/81ed9a62.aspx
Cheers all!
VB.NET 不区分大小写！这相当于：
作为我们团队环境中的标准，我们将使用：
VB.NET isn't case sensitive! This equates to:
As a standard in our team environment we would use: