Option Strict On and .NET for VB6 programmers

Question

Hi,

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?

Answer 1

Time spent developing with Option Strict enable will save you tremendous amount of debugging time later on.

Answer 2

YES!!!!

In my opinion, both as a developer, and as a college instructor YES.

It is best to get into the good habits from the start, it makes the whole process much easier, and Option Strict is one of those items that in my opinion is a NEEDED element.

added

There are literally tons of reasons that could be listed as to why, but the key is that it is a best practice, and when teaching a new language, it is key to teach those best practices from the start.

Answer 3

If you're used to having your types checked, then you probably want option strict on. turning it off can have advantages, but if your brain isn't tuned to spotting errors where your compiler would usually complain, then I would say to leave it on. I've worked in VB.Net a lot, and I have to say, that even though I work with options strict turned off most of the time, I've seen plenty of situations where having it turned on would have prevented quite a few bugs.

Answer 4

I agree with all of your answers. But by looking at how dynamic languages have become increasingly popular, I wonder whether the risk of removing the compile-time type checking can be mitigated by making good use of testing practices, like Unit Testing.

However my primary concern is to teach the best practices when developing on the CLR. Is Option Strict On a best practice in .NET? If so, why did Microsoft choose to disable it by default in Visual Studio?

Answer 5

Option Strict obviously can't replace good unit testing – but neither the other way round. While unit testing can detect the same errors as Option Strict, this implies that there's no error in the unit tests, that unit testing is done often and early, etc ….

Writing good unit tests isn't always trivial and takes time. However, the compiler already implements some of the tests – in the form of type checking. At the very least, this saves time. More likely, this saves a lot of time and money (at least occasionally) because your tests were erroneous / didn't cover all cases / forgot to account for changes in the code.

To sum it up, there's no guarantee that your unit tests are correct. On the other hand, there's a strong guarantee that the type checking performed by the compiler is correct or at least that its glitches (unchecked array covariance, bugs with circular references …) are well-known and well-documented.

Another sum-up: Yes, Option Strict On is definitely best practice. In fact, I've worked for years in online communities like this one. Whenever someone needed help on code that obviously didn't have Option Strict enabled, we'd politely point this out and refuse to give any further help until this was fixed. It saves so much time. Often, the problem was gone after this. This is somewhat analogous to using correct HTML when asking help in a HTML support forum: invalid HTML might work, but then again, it might not and be the cause of the problems. Therefore, many professionals refuse to help.

Answer 6

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.

Answer 7

Remember there are two levels here.

Option Explicit Option Strict

The main difference between the two is that Option Strict disable VB's automatic conversion of different data types. You have to explicitly use CType or another data conversion function to assign a variable to another type.

I been using VB since 1.0 and while I can see the point of this I think that Strict is over zealous paritcularily when dealing with Objects that have implemented or inherited different interfaces and classes.

I would start with Strict at first and if it starts getting in your way then drop down to Explicit. But don't ever both turn off, that way lies madness and excessive debugging time.

Over the years with VB I pretty much use Double for all floating point variables. This way you avoid many problems with rounding and loss of accuracy. In VB6 I used long as it was a 32-bit integer, but Integer work just as well in .NET as it is a Int32. I also recommend using Int32, Int16, etc instead of Integer,Long, etc in case Microsoft ever decides to redefine those keywords.

Answer 8

I'm going to disagree with RS Conley (very unusual). My favourite VB6 gurus - Francesco Balena, Dan Appleman - all disliked VB6's automatic conversion, and are in favour of Option Strict in .NET. Many experienced VB6 programmers know automatic conversion as "evil type coercion" (pdf), and will be delighted to switch on Option Strict.

It's occasionally better to use one small module without Option Strict, to avoid lots of complicated reflection code. But that's the exception that proves the rule.

Answer 9

Given Boehm's notion that fixing a problem earlier in the development cycle consumes the least resources, I'm a fan of every tool that helps developers "get it right" as early as possible. For this reason, I'm an advocate of things like IntelliSense that is both an efficiency boost as well as a tool that helps you implement working code earlier in the cycle. (Working, but not necessarily correct.)

For this reason, I also support the use of Option Strict as a way to help keep missteps and the consequent corrections deep into "design time."