Identifier Confusion in VB.NET

Tuesday, September 13, 2005

Understanding the semantics of a VB.NET program is sometimes hard. Sure, the language has got many descriptive keywords, and the names exported by its libraries actually make sense.

However, the language's loose syntax rules, designed to make it "easy", lead to many situation where the correct meaning of a line of code can only be determined by looking at the greater context. This is especially true when considering the growing complexity of the language.

Part of understanding what a program does is recognizing it's syntactical structure. Before we know what an identifier means in the constext of a program, we need to know what it is at the language level. Look at the following expression:

Foo.Bar.Bazz

This is non-obvious in any language. In C#, we could rule out any method calls. We could also be sure that there are no references to type names or static members after we have identified the first instance member. In VB.NET, there are more possibilities. Here are some examples:

• Namespace.Type.SharedProperty
• Type.SharedMethod.SharedProperty
• InstanceProperty.InstanceProperty.InstanceMethod
• InstanceField.InstanceMethod.InstanceProperty
• InstanceField.InstanceMethod.InstanceProperty
• ImportedSharedField.InstanceProperty.InstanceMethod
• LocalVariable.InstanceField.InstanceProperty
• LocalVariable.Type.SharedProperty

Some items on the list may be surprising. But remember VB.NET's features, all innocently designed for convenience:

• Accessing shared members via a reference.
• Accessing even types via an expression.
• Accessing instance members via type name (default instance).
• Static imports (ig. Imports SomeType).
• No parens needed in calls to parameterless methods.

Last but not least, although the language itself is innocent here:

• Naming conventions that prefer PascalCasing for everything.