Reputation: 35557
This is ok in C#
:
private int total;
public int Total {
get {
return total;
}
}
So the backing field total
is spelled the same as the Property
Total
with the only thing telling them apart being the case of the T
.
With VB.NET
VS complains if I try to do the following. In fact it won't even let me write Return total
with a lower case t
and auto-corrects to an upper case T
But if I spell the backing field differently then it seems to be ok:
Private fTotal As Integer
Public ReadOnly Property Total() As Integer
Get
Return fTotal
End Get
End Property
I realize they are different languages but is there a logical reason behind this difference? (EDIT originally said "apparent inconsistency" rather than "difference")
Also - I assume even though Visual Studio auto-corrects the case of my VB.NET but in reality this language is not case-sensitive?
Upvotes: 2
Views: 6435
Reputation: 6542
Actually, the problem here is nothing to do with the different case field named 'total'. You'll see the same problem if you remove that field.
The problem is that VB allows you to optionally set the value to be returned by a property or a function via a hidden local variable named the same as the property or function and then to return that hidden variable.
e.g., this will work:
Public ReadOnly Property Total() As Integer
Get
Total = 3 'setting the hidden VB variable
Return Total 'returning the hidden VB variable
End Get
End Property
VB even allows omitting the return statement in this case:
Public ReadOnly Property Total() As Integer
Get
Total = 3 'setting the hidden VB variable
End Get 'since the hidden VB variable was set, it is returned implicitly
End Property
These sort of VB-isms can make it very frustrating to interpret what is really happening in VB code.
Upvotes: 0
Reputation: 19335
There are several points to address:
The language Visual Basic is always case-insensitive. The compiler doesn't care if you declare a variable one way and use it another.
The IDE (Visual Studio) will helpfully fix the case of variable usages to match the actual declaration. You may be able to turn this off in the settings, but I've never tried so I don't know if it's actually possible.
Now back to your code:
Private total As Integer
Public ReadOnly Property Total() As Integer
Get
Return Total
End Get
End Property
There are actually two bugs here:
You have two members with the same name, a field called total
and a property called Total
. They're the same name because they're compared case-insensitively (the compiler shows you an error for this - the blue squiggly line in your screenshot).
The IDE auto-corrects 'total' to 'Total' inside the property, because you're actually referring to the property, not the field. The compiler won't show you an error because of this, but if you were to remove the field (so that your program compiles), you will run into a stack overflow at runtime because the property would call itself. Note that even if you did manage to turn of the IDE's auto-correct, you'd still be referring to the property, since it's looked up case-insensitively.
Upvotes: 1
Reputation: 545628
I realize they are different languages but is there a logical reason behind this apparent inconsistency?
The original reason is simply historical: VB is based on BASIC which, like other languages at the time (FORTRAN) was case insensitive (but was usually written in all-uppercase).
Furthermore, I don’t see any inconsistency: inside VB, the casing is entirely consistent. In particular, it’s not “sort of case-sensitive” as your title asks.
There is a logical reason to be case insensitive, even today: it makes it harder to introduce bugs due to name clashes; consider the following C# code:
private int total;
public int Total {
get { return total; }
set { Total = value; }
}
Did you spot the error immediately? If so, not bad (the syntax highlight here helps). In VB, this class of errors cannot happen. But in practice I think this class of bugs isn’t all that problematic because once identified they are easily eliminated. So while this is a reason for case insensitivity, it’s not a very strong one.
Finally, notice that Windows and OS X file systems use the same convention as VB here: the file system is case insensitive (filename case doesn’t matter) but case aware – meaning the file system preserves the original casing of a filename and displays it correctly but when comparing, it doesn’t consider case.
Upvotes: 5
Reputation: 3398
The VB.Net compiler is case insensitive in so far that for all intent and purposes it forbids the use of fields with the same name and the only difference of a upper case or lower case letter.
The underlying CLI (common language interface) and CLR (common language runtime) do support case differences. However the c# example given is not CLS valid.
Upvotes: 0
Reputation: 23084
VB.NET is not case-sensitive, it was designed to be easy to learn for Visual Basic programmers, and shares this trait with Visual Basic.
C# is case-sensitive, it's a different language than VB.NET. Even if they are both used for .NET development, they don't have to be consistent. You can use many languages for .NET development, and the differences between these languages are many and not limited to case-sensitivity.
Upvotes: 1