Search code examples
.netvb.netlate-binding

Option Strict On and .NET for VB6 programmers

I'm preparing a class on Visual Basic 2005 targeting Visual Basic 6 programmers migrating to the .NET platform.

I would like a word of advice about whether to recommend them to always enable Option Strict or not.

I've worked exclusively with C-style programming languages, mostly Java and C#, so for me explicit casting is something I always expect I have to do, since it's never been an option.
However I recognize the value of working with a language that has built-in support for late-binding, because not having to be excessively explicit about types in the code indeed saves time. This is further proved by the popular diffusion of dynamic typed languages, even on the .NET platform with the Dynamic Language Runtime.

With this in mind, should someone who is approaching .NET for the first time using VB.NET and with a VB6 background be encouraged to get into the mindset of having to work with compile-time type checking because that's the "best practice" in the CLR? Or is it "OK" to continue enjoying the benefits of late-binding?

Solution

  • Yes! Option Strict is definitely a best practice with .Net. Emphasize that .Net is at it's core a strongly typed platform, and will be until the DLR is more completely supported. With few exceptions, every Dim and Function should have an explicit type declared to go with it. Things like LINQ or Boo and JScript are the exceptions that prove the rule.

    Here are some other things to point out. I'm sure you're well aware of all this, but I've had to work with and maintain a lot of VB.Net code written by former VB6ers, and so this is something of a sore spot for me:

    • Don't use the old string functions: LEN(), REPLACE(), TRIM(), etc
    • Hungarian warts are no longer recommended. oMyObject and sMyString are not kosher. Show them the reference in Microsoft's Design Guidelines if they don't believe you.
    • Make sure they learn about the new AndAlso/OrElse logical operators
    • PARAMETERIZED QUERIES and modern ADO.Net. Can't emphasize that enough. They should never need to call CreateObject() again.
    • Scope works differently (and is more important) in .Net than it was in VB6. VB.Net still has modules, but they're now more analogous to a static class. It's important to understand how developing in a real object oriented environment be different, as opposed to the partial OOP support provided by VB6. There's no good reason anymore to allow methods to run to ungodly lengths.
    • Make sure they get an introduction to Generics and Interfaces (including IEnumeralbe(Of T)), and learn why they should never use an ArrayList again.

    I could keep going, but I'll just point you to the Hidden Features of VB.Net Question to close out this rant.