4

在最近的一个 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...) 中重命名与类同名的变量，但不是对该变量的其他引用，导致编译器问题（duh）。不过，这些总是很容易纠正。

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

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

4

9 回答 9

7

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

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

于 2009-08-28T15:04:19.307 回答
4

我必须在 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 让您在这方面更有信心。

于 2009-08-28T15:06:16.280 回答
2

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

于 2009-08-28T15:10:11.453 回答
2

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

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

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

于 2009-08-28T17:50:08.950 回答
1

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

一个更好的实践是尝试在变量被使用的上下文中命名变量，而不仅仅是类型名称。这导致了自记录代码并且需要更少的注释（注释被大量滥用作为编写密集代码的借口）。

于 2009-08-28T15:08:43.123 回答
1

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

于 2009-08-28T15:22:07.420 回答
1

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

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

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

于 2009-08-28T19:45:48.717 回答
0

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

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

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

Dim oFoo as New Foo 'VB.NET
于 2009-08-28T15:03:04.787 回答
0

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

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

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

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

大家干杯！

于 2009-08-28T19:21:28.767 回答