Option Strict On and .NET for VB6 programmers
.net, late-binding, vb.net
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.
Problem
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?