I just noticed that Option Explicit is on by default for new VB solutions in Visual Studio .NET 2005:
???
Option Explicit Off has been the default in the product since VS 2002. I’m not sure how the people you work with have managed to turn it off, but I can ASSURE you that we’ve shipped it with it off, for exactly the reason you state - it was too easy for misspellings to create new variables.
Er-- you’re right. How did they manage to turn it off? I don’t know why I work(ed) with such knuckleheads. Let me update the post to reflect the correction.
Indeed, Explicit On is the default:
http://support.microsoft.com/default.aspx?kbid=311329
My current clean install of VS.NET 2003 doesn’t contain either Explicit or Strict, so it’s fully default (not specified), and Explicit is definitely enforced.
I’m pretty sure now I was thinking of Option Strict the whole time, which is not on by default. Mea culpa.
I agree with Mr. Appleman, strict should be on as well.
No problem… As for the Option Strict thing, yeah, well, that’s something we get a lot of feedback on. We’ll just have to see… 
If people want the stricter option, why don’t they just go for C#?
VB will always make a poor static language in my opinion. Keep its strengts, keep it dynamic, but make the dynamics both safer and faster.
Well… considering the BCL TryParse sample I posted about today (granted, it’s from Oct 2003) had a static bug in it*, I’m inclined to think it should be on by default.
It’s definitely USEFUL, but I think having it on all the time is a mistake. It should be turned off as necessary for interop and other situations that warrant its use (or if the developer prefers it).
Couldn’t this be done rather simply with project templates? Kind of like how VS.NET 2005 makes you select a development profile at install time (general, web, C#, etc). You could select “VB-loose” or “VB-strict”.
Keep in mind the whole families of Python-like languages in which assignment is declaration and all typing is dynamic (everything’s Var) - and tons of useful apps have been made in these languages.
It takes practice to be that careful, but you can create much less verbose, more legible code if you do - plus it’s faster for quick one-offs.
Each approach has their place. Obviously if we’re talking about some rigorous financial enterprise application, all safety should be maximized - heck, even typecasts should be avoided in that sort of environment.
I like option strict off even if the compiler tries to guess. It will do it only once and if you are smart you will learn its habits. As a seasoned programmer, I coded well over a million lines of code throughout my professional career in VB6 and VB.Net and I see absolutely no problem with using this option. Like anything else in life, you just have to know what you are doing…
“It’s almost as bad as making a language case sensitive.”
What’s the argument against case sensitive languages…? It’s one of the reasons I love C#…
Pxtl, typing in Python is dynamic, it is not weak. Everything is most certainly not a var. The following code will result in an error in python:
myVar = 12
myVar = test
@hobbit125: Actually you will not get an error. This is because 12 and text are merely being bound to identifier myVar, not declaring a variable.
Thank u
I think it is ok for people to program with option strict turned off, I just hope they work for my competitors.
However, my complaint with Option Strict, is that it is not smart enough to NOT throw an error when you assign a subtype to a supertype.
Anyone know what possible purpose this serves?
I can only think of 2 possible reasons:
I always program with it on because I want it to catch the obvious type problems, but wish it had the C# behavior of knowing you can assign a subtype foo to supertype fooBase without a cast.