Option Strict, Explicit, Infer

[dbasnett]

New posters / programmers should have the following settings as the defaults:

Option Strict On
Option Explicit On
Option Infer Off


How to specify the default settings for Visual Basic 2008 & 2010 projects. When a new project is created, the specified option statements will be added to the project header in the Code Editor. The options apply to all Visual Basic projects.

To access this dialog box, on the Tools menu, click Options, expand the Projects and Solutions folder, and then click VB Defaults.



How to specify the default settings for Visual Basic 2003 & 2005 projects. When a new project is created, the specified option statements will be added to the project header in the Code Editor. The options apply to all Visual Basic projects.

To access the VB Defaults dialog box, on the Tools menu, click Options, then select the Projects folder and click VB Defaults.

[techgnome]

It's always a good idea. sometimes a lot of the errors come from the fact that Strict and Explicit are off... the infer.... I waffle on that... but I think that for beginners at least, infer should also be off... if you can do what you need to do in the most restrictive settings... then you'll be better for it in the long run and once you've mastered the basics, and have good foundation, then you can start doing things that seem to violate good practices (like turning infer back on).


-tg

[dbasnett]

I miss Stargate SG-1, and Atlantis. So glad Universe died

[Atheist]

Yes, I think so.

[JuggaloBrotha]

I miss Stargate SG-1, and Atlantis. So glad Universe died

Me too

As for this thread topic, I have to agree that for everyone Option Explicit and Strict should be on, for beginners Infer should be off (I still code with it turned off, then again I gotta everyone on the 2.0 FW so there's no need for it on really)

[Shaggy Hiker]

Frankly, I'd like a two out of three option in the poll, and it sounds like others feel that way, too. I'm pretty much indifferent to Option Infer, even for beginners. I don't think they really lose that much comprehension using that, and I don't know of any serious flaws that it creates. In fact, I would guess that at some point in the future, it might become the default.

[dbasnett]

Frankly, I'd like a two out of three option in the poll, and it sounds like others feel that way, too. I'm pretty much indifferent to Option Infer, even for beginners. I don't think they really lose that much comprehension using that, and I don't know of any serious flaws that it creates. In fact, I would guess that at some point in the future, it might become the default.

Aren't the defaults:

Explicit - On
Strict - Off
Infer - On

[FunkyDexter]

Personally I'd argue against Option Infer being on, even for experienced programmers. It's nowhere near as big a deal explicit or strict but I like clarity and I don't really see what benefit Option Infer gives you other than saving a few keystrokes.

[Atheist]

Personally I'd argue against Option Infer being on, even for experienced programmers. It's nowhere near as big a deal explicit or strict but I like clarity and I don't really see what benefit Option Infer gives you other than saving a few keystrokes.

+1.. Im generally against option infer. I can go as far as accepting its use when dealing with complex linq queries.

[Shaggy Hiker]

The only time I actually make use of Infer is with LINQ. I see no other use for it, and I guess I don't know what it defaults to, except that I generally don't care what it is set to, and on at least one of my VS installations it was off. Perhaps the default was Off for VS2008, and ON for VS2010. I don't know....and I pretty much don't really care, either.

[NickThissen]

I voted yes, but I'm not as convinced as everyone else seems to be...

Option Explicit, that's a no brainer and should always be on imo.

Option Strict? Well... It's simply a fact that you write better code when it's On, but that's not the only issue at play I think. The reason it is Off by default in the first place is to make VB more accessible, like the legacy VB was.

I think an important factor to keep in mind is experience. Everyone posting in this thread so far (as far as I know) has lots of experience with VB or at least .NET in general, and knows exactly why you shouldn't assign an integer to a string. But was this always the case? I am certain it wasn't for many of you, I'm sure most of you all started out with Option Strict Off at some point until you were 'ready' to turn it on. That was the case with me at least. When I turned it On for the first time I got lots of errors (as is common I guess). However, I didn't see this as a bad thing, I saw it as a challenge and wanted to learn why those errors popped up suddenly and how to avoid them. From that day on I suddenly understood how types worked in .NET a lot better.

I find it hard to decide whether it should be On or Off, I think both have their benefits. When it's Off by default, beginners get a chance to 'play' with the language before having to dive into the depths of type conversions. If they like it, they will figure out what option strict does soon enough (most likely via a forum like this or comments of someone else) and they can then work on learning the rest.

If you begin with Option Strict On, that's a huge part of the language you are FORCED to learn immediately and that might put people off. I think this is the main reason why VB is often said to be 'easy' compared to C# being 'hard' to learn. There isn't that much difference at all (and certainly the use of brackets versus more 'wordy' identifiers shouldn't be an issue on how difficult a language is to learn?) beside the fact that C# is always very strict when it comes to types and conversions.

I think most people that stick with programming in VB and decide to really learn it will eventually understand that Option Strict should be On and why.




As for Option Infer, I do use it a lot, especially for large type names, but only when the type is obvious. For example, when assigning a New instance of some class to a new variable, there isn't any doubt possible what the type should be.

Dim btn As Button = New Button()
Dim btn = New Button()   'how could btn be anything else than Button?

Another example is a function that returns an object, but the type of the object it returns is already in the name. I hate both having to type AND reading something like

Dim someVariable As SomeVeryLongTypeName = SomeVeryLongTypeNameFactory.GetSomeVeryLongTypeName()

It seems absolutely redundant (and it is) and I find it hard to read. Leaving out the type declaration here seems logical to me and makes it easier to read quickly.

As for it being On by default, no, I don't think so. Beginners might be confused with 'Dim x = 3' as x not having a type or being dynamically typed or something like that, while it is actually just a shortcut. Since it can mislead people this way I think it should be Off and turning it on should be a consious decision once you know what it does.

[techgnome]

The reason for Option Strict being on is more than just making the code more accessible or easier to work with. There is also a performance issue at stake. When Option Strict is off, EVERYTIME there is an assignment, the compiler (with VB6, or the JIT with .NET) has to do a check... can the right-hand operator be coerced into a type compatible with the left? The more complex the type, the greater a performance hit it is.

In addition, if things were taught with it on in the first place, then people would get those errors when they do turn it on. It's daunting when you flip one simple option and you suddenly have 50+ errors in your code and you're not skilled or equipped to know how to handle it. It becomes easier to just ignore them and turn it back off. Shortly after that, your next post at VBF will be about how to get more performance out of it because your loop locks up your UI. And then someone suggests threading...


-tg

[Shaggy Hiker]

Option Strict? Well... It's simply a fact that you write better code when it's On, but that's not the only issue at play I think. The reason it is Off by default in the first place is to make VB more accessible, like the legacy VB was.

I think an important factor to keep in mind is experience. Everyone posting in this thread so far (as far as I know) has lots of experience with VB or at least .NET in general, and knows exactly why you shouldn't assign an integer to a string. But was this always the case? I am certain it wasn't for many of you, I'm sure most of you all started out with Option Strict Off at some point until you were 'ready' to turn it on.

I didn't make the change because I was 'ready' basically, I left it in the default for a whole program because I didn't think it mattered all that much. Fortunately, the program was one that took a VERY long time to run. Flipping on Option Strict resulted in a boatload of errors, which took an hour or so to fix. There was nothing other than conversion errors where I was using implicit conversions.

The result was that the code ran MUCH faster. Exactly how much faster was a bit hard to say, as the runtime couldn't be predicted accurately, but the boost was around 30%. Not insignificant.

[dbasnett]

I didn't make the change because I was 'ready' basically, I left it in the default for a whole program because I didn't think it mattered all that much. Fortunately, the program was one that took a VERY long time to run. Flipping on Option Strict resulted in a boatload of errors, which took an hour or so to fix. There was nothing other than conversion errors where I was using implicit conversions.

The result was that the code ran MUCH faster. Exactly how much faster was a bit hard to say, as the runtime couldn't be predicted accurately, but the boost was around 30%. Not insignificant.

30% seems significant. e.g. if the code took an hour a 30% saving would mean 18 minutes saved.

[Shaggy Hiker]

The code took around three days, and with the change it was around two days. That was VERY significant, but hard to quantify precisely. After all, I wasn't even counting the hours, and the program could vary by an hour or two even if it was running the exact same problem, due to the nonlinnear nature of genetic algorithms.

EDIT: After a bit of testing, the situation is more complex than I had realized, and kind of interesting. Here's my test code:

Private Sub test1(ByVal arg As Object)
        Dim rating As Integer = 7
        Dim n As Double
        Dim x As Integer
        Dim td As Double = 1.1


        For x = 0 To 80000
            n += CDbl(arg)
        Next
        td = 1
    End Sub

I tried this with and without the CDbl (I had to have Option Strict OFF to do this without the CDbl), and with and without CInt(). The argument passed in was either 5 or "5" (a string literal). In all cases, Option Strict On was faster.

1) The performance for CDbl was slightly better than the performance for CInt in all tests where a string literal was being passed in, though only by about 5% or a bit more (37ms vs 40ms). This is partially because the number was being added to n, which is a double, so CInt converted to an integer, that was then promoted to a double to be added to a double. Changing n to an integer for those cases where I used CInt dropped the time to 39ms, so that isn't the only difference.

2) The performance for the two was the same between CDbl and CInt when the number 5 was passed in.

3) With Option Strict OFF, and a string literal passed in ("5"), the code took about a 10-15% hit, depending on whether it had been CDbl or CInt.

4) With Option Strict OFF, and the number 5 being passed in, the code took about 4x as long. Not 4%, 4x!! It was still vastly faster than converting a string literal into a number, which is probably the most common use of this, but still....

[kareninstructor]

I think this is a good idea. Perhaps there should be a sticky which goes in some details about why settings set a specific way are done and encourage Option Strict On.