Is VB really case insensitive?

Question

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 and SS and see what the compiler does.

EDIT Quote from Jeffrey Richter in the .NET Framework Design Guidelines page 45.

To be clear, the CLR is actually case-sensitive. Some programming languages, like Visual Basic, are case insensitive. When the Visual Basic compiler is trying to resolve a method call to a type defined in a case-sensitive language like C#, the compiler (not the CLR) figures out the actual case of the method's name and embeds it in metadata. The CLR knows nothing about this. Now if you are using reflection to bind to a method, the reflection APIs do offer the ability to do case-insensitive lookups. This is the extent to which the CLR offers case-insensitivity.

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 and datetime.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 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.

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:

For two identifiers to be considered distinct, they must differ by more than just their case.

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 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.

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 and SS are same.

Please have a look at VB.NET Basics tutorial for more information :)

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.