VB真的不区分大小写吗?
我不想在这里引发争论,但无论出于何种原因,通常都会指出 Visual Basic 不区分大小写,而 C 语言则不然(不知何故,这是一件好事)。
但我的问题是:Visual Basic 到底在哪里不区分大小写?当我
Dim ss As String
Dim SS As String
在 Visual Studio 2008 或 Visual Studio 2010 IDE,第二个有“本地变量 ”警告SS
已在当前块中声明”。在 VBA VBE 中,它不会立即踢出错误,而只是自动更正大小写。
我是否遗漏了 Visual Basic 不区分大小写这一论点? (另外,如果您知道或愿意回答,为什么这会是一件坏事?)
我为什么要问这个问题?
我在许多领域中使用过 Visual Basic其 方言已经很多年了,有时是 业余爱好者,有时是小 与商业相关的课程 工作组。截至过去六个月, 我一直在做一个大项目 比我预期的要大得多。很多 那里的示例源代码 是在 C# 中。我没有任何燃烧 想要学习C#,但是如果有的话 我在 C# 中错过的东西 提供 Visual Basic 不提供的功能(相反 VB.NET 提供 XML Literals),那么我想知道 有关该功能的更多信息。所以在这个 在这种情况下,人们常常认为 C 语言区分大小写并且 很好,Visual Basic 就是这样 不敏感,这是不好的。 ID 想知道...
- Visual Basic 究竟如何 不区分大小写,因为每个 代码编辑器中的单个示例 变得区分大小写(意味着 案件得到纠正)无论我想要 无论是否。
- 这足以让我信服吗 如果是 VB.NET,请考虑转向 C# 在某种程度上限制了我能做的事情 有代码吗?
I'm not trying to start an argument here, but for whatever reason, it's typically stated that Visual Basic is case insensitive and C languages aren't (and somehow that is a good thing).
But here's my question: Where exactly is Visual Basic case insensitive? When I type...
Dim ss As String
Dim SS As String
...into the Visual Studio 2008 or Visual Studio 2010 IDE, the second one has a warning of "Local variable SS
is already declared in the current block". In the VBA VBE, it doesn't immediately kick an error, but rather just auto-corrects the case.
Am I missing something here with this argument that Visual Basic is not case sensitive? (Also, if you know or care to answer, why would that be a bad thing?)
Why am I even asking this question?
I've used Visual Basic in many of its
dialects for years now, sometimes as
a hobbyist, sometimes for small
business-related programs in a
workgroup. As of the last six months,
I've been working on a big project,
much bigger than I anticipated. Much
of the sample source code out there
is in C#. I don't have any burning
desire to learn C#, but if there are
things I'm missing out on that C#
offers that Visual Basic doesn't (an opposite
would be VB.NET offers XML Literals), then I'd like to know
more about that feature. So in this
case, it's often argued that C
languages are case sensitive and
that's good and Visual Basic is case
insensitive and that is bad. I'd
like to know...
- How exactly is Visual Basic
case insensitive since every
single example in the code editor
becomes case sensitive (meaning
the case gets corrected) whether I want
it or not. - Is this compelling enough for me to
consider moving to C# if VB.NET case
is somehow limiting what I could do
with code?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(13)
VBA 和 VB.NET 之间的区别只是因为 VB.NET 在后台持续编译。编译 VBA 时会出现错误。
正如 Jonathan 所说,在编程时,您可以将 VB.NET 视为除了字符串比较、XML 和其他一些情况之外,不区分大小写...
我认为您对幕后的内容感兴趣。好吧,.NET 公共语言运行时区分大小写,而 VB.NET 代码依赖于运行时,因此您可以看到它在运行时必须区分大小写,例如当它查找变量和方法。
VB.NET 编译器和编辑器允许您忽略这一点 - 因为它们更正代码中的大小写。
如果您尝试使用动态功能或后期绑定(Option Strict Off),您可以证明底层运行时是区分大小写的。另一种了解这一点的方法是认识到像 C# 这样区分大小写的语言使用相同的运行时,因此运行时显然支持区分大小写。
编辑如果您想将 IDE 排除在外,您可以随时 从命令行编译。在 记事本 中编辑代码,使其具有
ss
和SS
看看编译器做了什么。编辑引用Jeffrey Richter在.NET Framework 设计指南第 45 页。
The difference between VBA and VB.NET is just because VB.NET compiles continuously in the background. You'll get an error when you compile the VBA.
Like Jonathan says, when programming you can think of VB.NET as case-insensitive apart from string-comparisons, XML, and a few other situations...
I think you're interested in what's under the hood. Well, the .NET Common Language Runtime is case-sensitive, and VB.NET code relies on the runtime, so you can see it must be case-sensitive at runtime, e.g. when it's looking up variables and methods.
The VB.NET compiler and editor let you ignore that - because they correct the case in your code.
If you play around with dynamic features or late-binding (Option Strict Off) you can prove that the underlying run-time is case-sensitive. Another way to see that is to realise that case-sensitive languages like C# use the same runtime, so the runtime obviously supports case-sensitivity.
EDIT If you want to take the IDE out of the equation, you can always compile from the command-line. Edit your code in Notepad so it has
ss
andSS
and see what the compiler does.EDIT Quote from Jeffrey Richter in the .NET Framework Design Guidelines page 45.
这里的部分问题是您需要将语言与 IDE 体验分开。
作为一种语言,VB.NET 对于标识符来说肯定是不区分大小写的。调用
DateTime.Parse
和datetime.parse
将绑定到完全相同的代码。与 C# 等语言不同,不可能定义仅大小写不同的方法或类型。作为一个 IDE,VB.NET 在漂亮地列出代码块时会尝试保留现有标识符的大小写。每当您离开当前逻辑代码行时,就会出现漂亮的列表。在这种情况下,您离开了
SS
的第二个声明,漂亮的列表器注意到存在具有该名称的现有标识符,并将其更正为具有匹配的大小写。不过,这种行为纯粹是为了增加用户价值。它不是核心语言的一部分。
Part of the problem here is you need to divide the language from the IDE experience.
As a language, VB.NET is certainly a case insensitive with respect to identifiers. Calling
DateTime.Parse
anddatetime.parse
will bind to the exact same code. And unlike languages like C#, it is not possible to define methods or types which differ only by case.As an IDE, VB.NET attempts to preserve the case of existing identifiers when it pretty lists a block of code. Pretty lists occur whenever you move off of the current logical line of code. In this case you move off of the second declaration of
SS
, the pretty lister notices there is an existing identifier with that name and corrects it to have matching case.This behavior, though, is purely done as a user value add. It is not a part of the core language.
VB大部分不区分大小写,但也有例外。例如,XML 文本和理解是区分大小写的。与 T-SQL 不同,字符串比较通常区分大小写,但有编译器开关可以使字符串比较不区分大小写。当然,在处理继承、COM 和动态语言运行时时也存在一些边缘情况。
VB is mostly case insensitive, but there are exceptions. For example, XML literals and comprehension is case sensitive. String comparisons are usually case sensitive, unlike say T-SQL, but there are compiler switch to make string comparisons case insensitive. And of course there are the edge cases when dealing with inheritance, COM, and Dynamic Language Runtime.
是的,VB.NET 编译器以不区分大小写的方式处理标识符。是的,当它使用用其他语言编写的程序集或使用 COM 组件时,可能会导致问题。 通用语言规范涵盖了前一种情况。相关规则是:
COM 大小写由类型库构建器相当粗略地处理,它强制具有相同名称的标识符的大小写相同。即使这些标识符具有不同的角色。换句话说,名称为“index”的方法参数将强制方法名称“Index”重新命名为“index”。正如你可能想象的那样,这引起了很多人的头疼:)
Yes, the VB.NET compiler treats identifiers in a case insensitive way. And yes, that can cause problems when it consumes assemblies that were written in another language or uses COM components. The former case is covered by the Common Language Specification. The relevant rule is:
The COM case is rather crudely taken care of by the type library builder, it forces the casing of identifiers with the same name to be identical. Even when those identifiers have different roles. In other words, a method parameter with the name "index" will force a method name "Index" to be recased to "index". That has produced rather a lot of head scratching, as you might imagine :)
VB 保留大小写(在 IDE 中),但不区分大小写。在某种程度上,它类似于 Windows 文件系统。 Hello.txt 和 hello.txt 被认为是相同的文件名。
IDE 假定变量的声明是该变量的“正确”情况,并调整该变量的每个实例以匹配声明。这样做是为了美观和一致性的原因,而不是为了功能。
我见过一些情况,其中大小写没有自动更改以匹配声明,并且该语句的工作原理是一样的。您还可以使用任何文本编辑器编写在不同情况下都能正常编译的代码。
旁注:
大多数人们以不区分大小写的方式思考。当我们看到“狗”这个词时,这个词就会被翻译成我们心中的意思。该单词的含义不取决于大小写(即,无论是否将其拼写为“DOG”、“DoG”或“dOG”,仍然会吠叫。)计算机将单词视为离散的位包。大写和小写是不同的位模式,因此是不同的。
由于大多数程序员都是人类,因此不区分大小写似乎更适合人们的思维方式,而区分大小写则更多地是人类根据机器的限制调整他们的思维方式。
VB is case preserving (in the IDE) but case insensitive. It's like Windows file system in a way. Hello.txt and hello.txt are considered to be the same file name.
The IDE assumes that the declaration a variable is the "correct" case for that variable, and adjusts every instance of that variable match the declaration. It does this for eye-candy and consistency reasons, but not for functionality.
I've seen several instances where the case was not automatically changed to match the declaration, and the statement works just the same. You can also use any text editor to write code that will compile just fine in different cases.
A side-note:
Most PEOPLE think in a case-insensitive manner. When we see the word "dog" the word is translated into meaning in our minds. The meaning of the word is not based upon case (i.e. regardless of if spell it "DOG", "DoG", or "dOG" still barks.) COMPUTERS see words as discrete bags of bits. Uppercase and lowercase are different bit patterns, and are thus different.
Since most programmers are human, case insensitivity seems more adapted to the way people think and case sensitivity is more about humans adapting how they think to the constraints of a machine.
这是您正在使用的编辑器的一部分,它们的行为可能有所不同,但事实是 Visual Basic 确实是不区分大小写的语言。因此,
ss
和SS
是相同的。请查看 VB.NET 基础教程以获取更多信息:)
This is part of the editor you are using, they may behave differently but the fact is that Visual Basic really is case-insensitive language. So,
ss
andSS
are same.Please have a look at VB.NET Basics tutorial for more information :)
我不确定我是否理解你的意思? VB 不区分大小写,因此 ss 和 SS 是同一个变量,因此编译器正确地抱怨您重新声明了该变量。
我认为变量不区分大小写,但函数名称区分大小写。
I'm not sure I understand you? VB is case insensitive, so ss and SS is the same variable, so the compiler correctly complains that you re-declared the variable.
I think that Variables are not case sensitive, but function names are.
是的,VB 不区分大小写。有时它会让那些不习惯的人陷入困境。
Yes, VB is case insensitive. It sometimes throws those not used to it for a bit of a loop.
人们不必在 VB.NET 中费尽全力来创建具有不同大写/小写“拼写”的标识符的代码。在不使用“重命名”功能的情况下更改声明文件中标识符的大小写不会导致其他文件中的名称被更新,但编辑包含该名称的任何行将使其符合当前定义。
通过这种方式,我们可以确定 VB.NET 大多不区分大小写,但它确实使标识符的大小写可供 CLR 使用,CLR 可以以区分大小写的方式使用该信息。
One doesn't have to try all that hard in VB.NET to create code with different uppercase/lowercase "spellings" of an identifier. Changing the casing of an identifier in the file where it's declared without using the "Rename" function will not cause the name to be updated in other files, though editing any line which contains the name will cause it to conform to the present definition.
In this way, one can determine that VB.NET is mostly case insensitive, but it does make the case of identifiers available to the CLR which may use that information in case-sensitive ways.
我将尝试回答你的第二个问题。
“如果 VB.NET 案例在某种程度上限制了我使用代码的能力,这是否足以让我考虑转向 C#?”
使用 C# 创建 WCF WebService。创建数据契约(1 类)。具有“字符串电子邮件”属性的一种。另一个以“字符串电子邮件”作为另一个属性。您选择将其理解为个人电子邮件或办公室电子邮件。或者它可能位于两个不同的数据合同中。
对于 C# 来说这很好。 Web 服务创建得很好。 AC# 程序可以轻松创建 WSDL,一切都很好。
现在尝试使用 VB(任何版本)创建 WSDL。它会说“email”已经声明并且 WSDL 生成失败。
和大家一样,我认为这是 VB 语言的一个缺点。但!!!
使用 FxCOP 并分析原始 C# 代码。 FxCOP 表示使用电子邮件/电子邮件是一个问题。建议使用不同的名称,支持不区分大小写。另请注意,截至目前,.NET 框架有 106 种编程语言,并且许多语言都启用了区分大小写。我们都在向云迈进,并希望所有编程平台/语言都可以访问我们的服务。
因此,区分大小写是您在程序中的选择,如果您是 C 人,您会喜欢它。如果该程序要被其他非 C 程序使用/访问,您需要支持不区分大小写,但您的语言是您的选择。
http://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Visual_Basic_.NET
http://www.vbrad.com/article.aspx?id=65
I'll try to answer your second question.
"is this compelling enough for me to consider moving to C# if VB.NET case is somehow limiting what I could do with code?"
Create a WCF WebService using C#. Create a DataContract (1 Class). One with "string email" property. Another with "string Email" as another property. Your choice to understand as personal email or office email. Or it could be in two different DataContracts.
For C# this is fine. The web service is created fine. A C# program can easily create a WSDL and everything is fine.
Now try to create a WSDL with VB (any version). It will say "email" is already declared and WSDL generation fails.
Like everyone I assumed this is a drawback in VB language. But!!!
Use FxCOP and analyze the original C# code. FxCOP says using email/Email is an issue. Recommends to use different name supporting case insensitivity. Also note as of date .NET framework has 106 programming languages and there are many languages having case sensitivity ON. We are all moving towards cloud and want our services to be accessible by all programming platform/languages.
So being case sensitive is your choice within your program and if you are C guy you would like it. If the program is going to be used/accessed by other non C programs you need to support case insensitivity but your language is your choice.
http://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Visual_Basic_.NET
http://www.vbrad.com/article.aspx?id=65
我没有看到任何人对你最后明确的第二个问题发表评论:“2:如果 VB.NET 案例在某种程度上限制了我可以用代码做什么,这是否足以让我考虑转向 C#?”
我更喜欢 C# 让程序员选择是否提供更多选项的方法,而不是限制程序员的选项。我非常喜欢 C#,但仅就区分大小写而言,我什至不认为它与学习一门语言很接近,因为它区分大小写。所有功能都很重要,当我考虑 C# 和 VB.NET 的优点时,我非常喜欢 C#。但我会给你一个真正平衡的观点,有偏见是的,因为我有偏好,但我也会诚实地对待 C# 的缺点。
首先,两种语言都有优点和缺点。在一种语言中可以做到而在另一种语言中无法做到的差异正在缩小,值得庆幸的是,微软正在改进这两种语言,而且他们似乎并没有对任何一种语言表现出不公平的偏袒。
当 C# 第一次出现时,VB 没有可以放在方法之前的 XML 注释,而我在 C# 中喜欢这样做。我讨厌 VB.NET 中的这一点。但多年来我发现,一种语言中没有的许多功能被添加到另一种语言中。 (同一个 MS 开发团队同时开发 C# 和 VB,因此这些功能应该变得非常相似是有道理的。)
但是您询问 C# 有哪些 VB 没有的功能。以下是我立即能想到的一些内容:
1:C# 在很多方面都更加简洁,并且需要更少的打字!我什至看到过一些愚蠢的说法,即 VB 可以节省打字。但请听听那些告诉你他们使用这两种语言的人的意见,而且他们很少使用这两种语言。我在家里使用 C# 和 VB,因为我喜欢它(当我在工作中使用 C# 时),而且我最近的工作要求我使用 VB 而不是 C#。所以我现在更频繁地使用 VB(大约 10 个月了),但在我个人的见证中,我更喜欢 C#,并且就实际打字而言,VB 的打字要多得多。我读过的一个例子中,有人实际上试图说 VB 更简洁,给出了一个“with ...”示例,其中包含一个长变量,因此在 VB 中,您可以只使用“.property”。声称 VB 需要更少的打字是愚蠢的。在实际实践中,在某些情况下(不仅仅是这个例子)VB 更短,但更多时候 C# 更简洁。
但我认为 C# 更简洁的最大原因是 VB 冗长的“IF/THEN”语句。 if 语句很常见。在 C# 中,没有“then”这个词需要输入! :) 另外,所有“end ...”语句都需要输入,在 C# 中,通常只是一个右大括号“}”。我读到,有些人声称 VB.NET 中的这种更详细的内容对 VB 来说是一个优势,因为多个结束块语句/符号可以嵌套并立即彼此相邻结束,但我非常不同意。一个人几乎总是可以比其他程序员更好地用 C# 或 VB 编写程序,因为下一个代码修订版可以设计得更好。这适用于“C# 中令人困惑的大量右大括号”,此外,如果嵌套块都是相同类型(如多个嵌套 IF),那么 VB 会遇到与 C# 中相同的问题。这在VB中是没有优势的。这种情况正是为什么我喜欢评论我的结束符号或结束语在两种语言中的搭配。是的,这样做比较冗长,但无论使用哪种语言,您都可以选择清晰,这在基于判断的具体情况下非常重要。我认为代码清晰性非常重要。
2:VB没有多行注释。当我使用 VB 时,我并不介意。然后我又学习了一些C风格的语言。现在我回来了,工作中主要使用 VB.NET,我很想念它们。它只是你觉得方便,然后又不得不失去的东西。 :(
3: VB 的 'andalso' 和 'orelse' 是相当烦人的,而在 C# 中,它只是简单的 '&&' 和 '||'。再次,更少的打字。这在我的代码中并不罕见VB 和 C# 中,就功能而言,“OR”与“OrElse”通常并不重要,只是“OrElse”对于计算机来说速度更快,因此如果程序员在 VB 中只使用“Or”和“And”,那么它就可以了。对于喜欢代码清晰的人来说,“Or”比“OrElse”更容易浏览。4
:当一行很长并且您想将其换行时,C# 中的代码放置更加灵活。 ,我讨厌 VB.NET 对我的代码的“控制”重新调整,但我发现它在 C# 中更有用,而在 VB 中,它更具控制性,但这更多的是 VB.NET IDE。 C# IDE 而不是语言本身,但我不知道您是否想要两者或纯粹没有 IDE 差异的语言功能
5:我真正怀念的是在 C# 中创建一个新的代码块,我可能会发生很多事情。在一个方法中,我想在一个非常小的代码块中声明一个变量,但不想在整个方法的该代码块之外声明该变量。在 C# 中,我们可以使用“{”创建一个新块并以“}”结束。 VB 没有这样的功能,但最接近的匹配是无条件“If True then”和“End If”块。 (请注意 2 个字符的 C# 与 18 个字符的 VB.NET 的等效性...更多在 VB 中输入。)
6:自增和自减运算符:++ 和 -- 如
myVariable++
或++myVariable
或等效的递减版本。有时这会非常方便。这是我非常怀念 C# 时的实际代码示例:为了给出 C# 规则的一个很好的例子,这是我最近个人编写的更多代码:
也许这是 C# 更简洁的充分证据。但并不是所有的程序员都喜欢简洁。有些人更喜欢读“if a < b then...”,因为这对他们的人类语言来说更自然。那很好。偏好很好。对我来说,手的努力是我看重的一个因素,我认为任何人都可以习惯用他们喜欢的任何符号来思考,因为“if”和“then”是字母表的符号,而C#的“if(条件)语句;”语法也是符号。一种比另一种更接近非程序员的语法。我更喜欢简洁的。
我还认为需要在 VB 中的字符文字后面使用“c”以使其成为字符文字而不是字符串,这很烦人。我更喜欢 C# 的简洁性。当方法需要字符文字时,您需要提供一个字符而不是一个字符长度的字符串,因此有时您被迫在 VB 中使用
":"c
而在 C# 中则为':'
。我认为这是挑剔的。公平地说,我会说 VB 有一些优点,比如不必在方法调用后放置空括号,例如
Dim nameUpper$ = name.ToUpperInvariant
,其中 C# 需要空括号:字符串 nameUpper = name.ToUpperInvariant()
。或者加倍也喜欢修剪它:Dim nameUpper$ = name.Trim.ToUpperInvariant
与string nameUpper = name.Trim().ToUpperInvariant()
。我喜欢 VB 的简洁用法,即我刚刚使用上面的$
将其调暗为“作为字符串”,而 C# 没有这些快捷方式。 VB有String、Integer、Long、Decimal、Single、Double类型的快捷键,但缺点是不太清晰,所以我谨慎使用。但尽管如此,我还是更喜欢简洁的代码。嗯,这只是这位经验丰富的程序员的一些想法,据我所知,这是我对 C# 与 VB 的编程“见证”。在我看来,这两种语言都是很好的语言。但是,是的,我仍然更喜欢 C#。
ps 由于我计划一生中的大部分时间都在编程,所以我什至重新学习了使用最高效的键盘打字:德沃夏克键盘,它比在 Qwerty 键盘上输入英语大约需要 1/3 的努力。查一下。也许你也想切换。 ;) 它让我的打字轻松了 67%! :) 我鼓励任何人跳出框框思考并评估你的工作效率。 Dvorak 简化键盘布局和 C# 已经为我做到了这一点。 :)
PSS 我会将 Dvorak 和 C# 与公制进行比较,而不是 Qwerty 键盘布局,将 VB 与经验测量进行比较。 Dvorak、公制和 C# 都是“干净的”。但 VB 也不甘落后。但它确实需要向后兼容旧的 VB6 代码和 .NET 之前的代码,例如“Or”与“OrElse”以及“IIF()”。
我以谨慎结束。请更加谨慎,不要听那些并不真正知道自己在说什么的人。 VB 和 C# 的所有缺点中,有一半已经不再是问题了,人们仍然发帖称他们不知道该语言中仍然存在哪些缺点。我能想到的最好的例子是在 VB 中使用三重撇号或在 C# 中使用三重斜杠注释符号的方法的 XML 注释。但请你自己辨别一下,这个人的言论是出于无知,还是出于经验。个人见证意味着他们从自己的真实经历中得知。当某人拥有丰富的经验后,请竖起耳朵。我在 C# 和 VB 方面都有超过 10 年的经验。归结起来就是:两者都是(非常)好的语言。大多数差异,您可以在阅读代码后 5 分钟内立即看到。但是,是的,其他功能可能需要数年时间才能找到障碍。我意识到(在 C# 中)的一个障碍,我什至无法想象它在现实生活中有用的情况。所以也许这根本不是一个障碍。
快乐编码!
I've not seen anyone comment on your explicit 2nd question at the end: "2: is this compelling enough for me to consider moving to C# if VB.NET case is somehow limiting what I could do with code?"
i prefer the more option approach that C# lets the programmer choose whether than limiting the programmer's options. i highly prefer C#, but for case sensitivity alone, i would not even think it close to learning a language just because it is case sensitive. all the features are what matter, and when i look at advantages of both, C# and VB.NET, i highly prefer C#. but i will give you a true balanced perspective, biased yes, because i have a preference, but i will be honest about the disadvantages of C# too.
first off, both languages have advantages and disadvantages. the differences that you can do in one language that cannot be done in the other is dwindling as, thankfully, Microsoft is improving both languages, and they seem to not be showing unfair partiality toward either language.
when C# first came out, VB did not have its XML comments that you could put before methods, which i loved in C#. i hated that in VB.NET. but i've seen over the years, that many features that are not in one language get added to the other. (the same team of MS developers develop both C# and VB, so it makes sense that the features should become quite similar.)
but you asked for what C# has that VB doesn't. here's some i can think of immediately:
1: C# is more concise and takes less typing.. in MANY ways! i've even seen stupidity speaking when the opposite claim is made, that VB saves typing. but please listen to the people who tell you they use both languages, and neither is rarely used by them. i use both C# and VB, C# at home because i like it (and when i work with C# at work), and my more recent job requests that i use VB and not C#. so i'm getting more frequent use of VB now (for about 10 months now), but in my personal testimony, i much prefer C#, and in terms of actual typing, VB is considerably more typing. the one example i've read where someone actually tried to say VB was more concise, was giving a 'with ...' example with a long variable in the with, so in VB, you could just use '.property'. this is stupidity in claiming that VB needs less typing. there are a few things (and not just this example) where VB is shorter, but many more times when C# is more concise, in real practice.
but the biggest reason i believe C# is more concise, is VB's verbose "IF/THEN" statements. if statements are common. in C# there is no 'then' word to type! :) also all the 'end ...' statements take typing which in c#, is usually just one closing brace '}'. i've read that some people claim this more verboseness in VB.NET is an advantage to VB since several closing block statements/symbols can be nested and end immediately next to one another, but i quite disagree. a person can almost always write a program better in either C# or VB than another programmer because the next code revision could be designed better. this applies to the 'confusing numerous closing braces in C#' plus if the nested blocks are all the same type like several nested IF's then VB suffers the same problem as it has in C#. this is no advantage in VB. this situation is precisely why i like to comment what my closing symbol or closing statement goes with in both languages. yes, this is more verbose to do, but in either language, you have the option to be clear, which is important in judgement based, situational specific cases. i think code clarity is quite important.
2: VB does not have multi-line comments. when i worked with VB i didn't mind. then i went to a few C-style languages. now i'm back mostly using VB.NET at work, and i miss them. it's just something you find convenient, and then have to lose. :(
3: VB's 'andalso' and 'orelse' is rather annoying to type all that when in C# it is simply '&&' and '||'. again, less typing. this is not rare in my code in both VB and C#. if anything, for functionality, 'OR' vs 'OrElse' usually does not matter except 'OrElse' is faster for the computer, so if a programmer just uses 'Or' and 'And' in VB, then it produces less optimal code for someone who likes clarity of code. 'Or' is far easier to skim than 'OrElse'.
4: more flexibility in code placement in C#. when a line is long and you want to wrap it on the next line, i hate VB.NET's 'controling' readjusting of my code. C# does it a little, but i find it more useful in C#, where in VB, it is much more controling. but this is more of the VB.NET IDE vs C# IDE rather than the language itself. but i don't know whether you want both or purely the language features without IDE differences.
5: one i really miss is just creating a new block of code in C#, i might have a lot happening in a method and i want to declare a variable in a very small block of code but not have that variable declared outside that block in the entire method. in C#, we can just create a new block with '{' and end it with '}'. VB has no such feature, but it's closest match is an unconditional 'If True Then' and 'End If' block. (note the 2 character C# vs 18 character VB.NET equivalent again... more typing in VB.)
6: self increment and decrement operators: ++ and -- as in
myVariable++
or++myVariable
or the equivalent decrement versions. this comes in very handy... sometimes. here is an example of actual code when i missed C# greatly:And just to give a VERY good example where C# rules, this is more code that i personally wrote recently:
Perhaps this is enuf evidence that C# is more concise. But not all programmers like conciseness. Some prefer to read "if a < b then ... " because it is more natural to their human language. And that's just fine. Preferences are fine. For me, hand effort is a factor i value, and i think anyone can get used to thinking in any symbols they prefer, for "if" and "then" are symbols of an alphabet, and C#'s "if (condition) statement;" syntax are symbols too. one is just closer to non-programmer's syntax than the other. i prefer the concise one.
I also think needing to use 'c' after character literals in VB to make it a character literal rather than a string is annoying. I like C#'s conciseness with that much more. when a method requires a character literal, you need to provide a character not a string with one character length, so sometimes you are forced to use
":"c
in VB while in C# it is':'
. i think this is nit-picking tho.To be fair, i will say there are advantages i like to VB like not having to put empty parentheses after method calls, like
Dim nameUpper$ = name.ToUpperInvariant
where C# requires the empty parentheses:string nameUpper = name.ToUpperInvariant()
. or double that like trimming it too:Dim nameUpper$ = name.Trim.ToUpperInvariant
vsstring nameUpper = name.Trim().ToUpperInvariant()
. I like VB's concise use of how i just used$
above to dim it ' As String' where C# does not have those shortcuts. VB has those shortcuts for String, Integer, Long, Decimal, Single, and Double types, but the disadvantage is it is less clear, so i use it with caution. but nevertheless, i prefer concise code.Well, that's just some thots from this seasoned programmer, and as i consider, this is my programming 'testimony' of C# vs VB. both are nice languages tho, in my opinion. but yes, i still much prefer C#.
p.s. Since i plan to program for most of my life, i even re-learned to type using the most efficient keyboard: the Dvorak keyboard, which takes about 1/3 the effort to type English than on a Qwerty keyboard. look it up. maybe you might want to switch too. ;) it made my typing 67% easier! :) I encourage anyone to think outside the box and evaluate better efficiency in your work. The Dvorak Simplified Keyboard Layout and C# has done this for me. :)
P.S.S. i would compare the Dvorak and C# to metric as opposed to the Qwerty keyboard layout and VB to the Empirial measurements. Dvorak, metric, and C# are just 'clean'. BUT VB is not really far behind. But it does suffer from needing to be backward compatible to old VB6 code and pre .NET code, like the 'Or' vs 'OrElse', and 'IIF()'.
I finish with a caution. Please be more prudent that listening to people who do not really know what they are talking about. Half of all the cons against both VB and C# are not any issue anymore, and people still post about them being ignorant about what disadvantages really still do exist in the language. The best example i can think of is XML comments for methods using triple apostrophe in VB or triple slash comment symbols in C#. But please discern for yourself whether a person is speaking from ignorance, or from experience. Personal testimony means they know from their real experience. And after someone has lots of experience in it, then perk up your ears. I have more than 10 years experience in both C# and VB. And it boils down to this: both are (very) good languages. And most the differences, you can see immediately within 5 minutes of reading code. But yes, other features it may take years to find a handicap. And one handicap that i'm aware of (in C#), I can't even think of a real life situation where it would be useful. So perhaps it isn't a handicap after all.
Happy coding!
符号的隐藏(例如本地隐藏字段)也不区分大小写。
这是一个 示例:
VB.NET 编译器的输出被反编译为(因此等效于)以下 C#:
string.Equals
两次传递该字段。无论大小写,本地都是隐藏的。该语言不区分大小写。要显式引用 a 成员(例如此字段),您必须通过
Me
取消引用该成员:Hiding of symbols (eg. local hides field) is also case insensitive.
Here is an example:
The VB.NET compiler's output is decompiled to (and therefore equivalent to) the following C#:
string.Equals
is passed the field twice. The local is hidden, irrespective of case. The language is case insensitive.To explicitly reference the a member, such as this field, you must dereference the member via
Me
:VB.NET 不区分大小写。
示例:
1.
2.
3.
这些所有代码都会抛出编译时错误。
对于第一个示例,将显示错误,指出“局部变量'A'已在当前块中声明。”。
而对于第二个和第三个示例,将显示错误“‘Public Sub b()’具有具有相同签名的多个定义”。和“‘Public Function c() As Integer’具有多个具有相同签名的定义。”。
从这些错误中,请注意变量和过程/函数的错误是在不同位置引发的。对于变量,错误会在第二次声明时抛出,而对于过程/函数,错误会在相同代码的第一次声明/定义时抛出。
正如用户在上面的评论中所说,VB.NET 代码在后台不断检查和/或更正;您可以在 VS IDE 的“错误列表”窗口中看到此错误。由于这是一个错误并且不是警告,因此在解决错误之前代码不会编译。
VB.NET is case-INsensitive.
Examples:
1.
2.
3.
These all code will throw a COMPILE-TIME ERROR.
For the 1st example, error will be shown, saying "Local variable 'A' is already declared in the current block.".
While for the 2nd and 3rd example, error will be shown saying "'Public Sub b()' has multiple definitions with identical signatures." and "'Public Function c() As Integer' has multiple definitions with identical signatures.", respectively.
From these errors, note that the errors are thrown at different positions for variables and procedures/functions. For variables, error is thrown at 2nd declaration while for procedures/functions it is thrown at 1st declaration/definition of identical code.
As said by a user in a comment somewhere above, the VB.NET code is continuously checked and/or corrected in background; you can see this error in "Error List" window in VS IDE. And as this is AN ERROR and NOT A WARNING, the code will not compile until error is resolved.