Lets use Option Strict!

Hey guys, Swifty here, and i'd like to introduce a lot of you guys to a statement called Option Strict.

Option Strict is a relatively new concept that will disallow of certain, commonly used code structures and code segments. Essentially Option Strict enables strong typing (wiki: Strong and weak typing - Wikipedia, the free encyclopedia), in other words it calls for more restrictions and disallows of "lazy" or inefficient coding - to an extent.

So what exactly does this Option Strict limit?
To begin, Option Strict does not allow for undefined variables. For example, one cannot declare a variable in the following manner:

Code:

Dim a

Also, Option Strict does not allow for certain implicit conversions, such is the case when an integer is assigned a value using a string format (which is surprisingly common). Examples:
Incorrect:

Code:

Dim a as integer = "1"

Correct:

Code:

Dim a as integer = 1

Note that forbidden implicit conversions aren't limited to integer -> string conversions. Infact, all conversions are forbidden except for those that are widening conversions (conversions that don't allow lose of data, for more information in widening conversion, visit the MS link: Option Explicit and Option Strict in Visual Basic .NET and in Visual Basic). Additionally, conversions that lose accuracy either through dropped chars or rounding are permitted.

Also considered by Options Strict are instances of late binding.
To begin this section of the thread, I would first like to note, that whenever possible, the developer should always shoot for early binding, and never for late binding, I will elaborate now. Now, lets begin by defining what binding is. Binding i occurs whenever an instance of an object is assigned to an object variable is detected. There are fundamentally two kinds of bindings that are possible, early, and late. One of the main advantages of using early binding is efficiency.
Instances of both kinds of binding:
Early binding:

Code:

Dim my_info As System****.FileInfo
my_info = New System****.FileInfo("loc")

Late binding:

Code:

Dim ctrl As Object = sender.GetType()
Dim name_property As Object = type.GetProperty("Name")

There are a number of disadvantages associated with late binding.
For one, your program will debug and run significantly slower than applications applying early binding. This occurs as result of time spent determining the object type, something already defined in early binding. The IDE is great in that the JIT (just in time debugger) as well as the compiler can identify errors that run the potential of crashing your application. This "catch" is only evident in early binding. Finally, due to the simple fact that Intellisense doesn't work with string inputs, it most certainly won't work when identifying objects on runtime.

Almost forgot to mention how to enable Option Strict. As stated earlier, unlike Option Explicit (for another day), Option Strict by default is disabled. To enable it, Insert the following code at the top of your code:

Code:

Option Strict On

Further, to always have it enabled, simply visit: Tools -> Options -> Projects and Solutions -> VB Defaults -> Option Strict On

Thanks for reading guys! IF you have any questions, additions, or corrections, feel free to comment and let me know.

Thanks guys!
Swifty

Ok.. so was this meant to be a tutorial?

Originally Posted by DawgiiStylz

Ok.. so was this meant to be a tutorial?

I was putting out a suggestion. I have seen a lot of threads with contents that would not be permitted using Option Strict, and thought it would be a good idea for people to know it exists (which I know a fair amount don't).

---------- Post added at 08:36 PM ---------- Previous post was at 08:33 PM ----------

Originally Posted by Jason

Option Strict isn't that new (hasn't it always been part of VB.NET? I know it's been around since at least VS2005). Although I rarely (as little as possible) use VB anymore, when I did I'd usually have both Option Strict and Option Explicit on, although some of the late binding rules that Option Strict pedantically enforces are really irritating in some contexts, so often it got turned off.

As of like 2005, which relatively speaking is new, considering visual basic has been around since like 1991. And to go even farther back, Basic, which VB draws a lot of characteristics from, has been around since like 1964.

Originally Posted by swiftyspiffy

I was putting out a suggestion. I have seen a lot of threads with contents that would not be permitted using Option Strict, and thought it would be a good idea for people to know it exists (which I know a fair amount don't).

---------- Post added at 08:36 PM ---------- Previous post was at 08:33 PM ----------

As of like 2005, which relatively speaking is new, considering visual basic has been around since like 1991. And to go even farther back, Basic, which VB draws a lot of characteristics from, has been around since like 1964.

Except we're talking about VB.NET, not Visual Basic or BASIC or any of BASIC's predecessors and derivatives (let's not end up at FORTRAN shall we?). In addition I highly doubt anyone on this forum has been coding in BASIC since 1964, the majority of members only have a couple of years max experience in any kind of programming.. In this context Option Strict isn't any "newer" than the plethora of features added to VB.NET in the last 8+ years that everyone uses.

Nevertheless, it's a very minor point and not really worth nitpicking over.

Option Strict/Explicit can be great helpers for beginners to promote good programming practices from the start, but I tend to find that even without Option Strict on, I'll be writing code that conforms to the "strict" variation of VB.NET anyway (having moved to languages that are a lot less lenient than VB.NET in this regard). By all means, switch it on kids, stop your bad habits at the source.

(Point of irony: VB.NET itself facilitates these shitty habits, then provides essentially a compilation directive to say "Actually, please don't allow this terribad coding to compile, what were we thinking?")

Originally Posted by Jason

Except we're talking about VB.NET, not Visual Basic or BASIC or any of BASIC's predecessors and derivatives (let's not end up at FORTRAN shall we?). In addition I highly doubt anyone on this forum has been coding in BASIC since 1964, the majority of members only have a couple of years max experience in any kind of programming.. In this context Option Strict isn't any "newer" than the plethora of features added to VB.NET in the last 8+ years that everyone uses.

Nevertheless, it's a very minor point and not really worth nitpicking over.

Option Strict/Explicit can be great helpers for beginners to promote good programming practices from the start, but I tend to find that even without Option Strict on, I'll be writing code that conforms to the "strict" variation of VB.NET anyway (having moved to languages that are a lot less lenient than VB.NET in this regard). By all means, switch it on kids, stop your bad habits at the source.

(Point of irony: VB.NET itself facilitates these shitty habits, then provides essentially a compilation directive to say "Actually, please don't allow this terribad coding to compile, what were we thinking?")

I was just giving a reference of time. And you bring a solid point, in that VB facilitates poor programming habits. I just saw, while browsing this forum, a lot of instances that Strict could fix to some degree. Regardless though, hopefully this thread will have a positive impact on this forum.

Option Strict isn't that new (hasn't it always been part of VB.NET? I know it's been around since at least VS2005). Although I rarely (as little as possible) use VB anymore, when I did I'd usually have both Option Strict and Option Explicit on, although some of the late binding rules that Option Strict pedantically enforces are really irritating in some contexts, so often it got turned off.

All it does is prevent lazy coding.. its a personal choice really..

Originally Posted by DawgiiStylz

All it does is prevent lazy coding.. its a personal choice really..

False. Using Strict On prevents unneccesary casting and binding during runtime which can improve the speed of code. When I used to code in VB.NET, I used to always enable it. Plus it makes your code more explicit and more understandable.

For example, if you omit the type of a variable or function, it will automatically assume that it's an Object and when you use it in functions that expect something else, the .NET runtime needs to unbox the value if it's a value type (Integer, Single, Short, etc) or cast it to something else. Not to mention when you access fields/properties using late binding the runtime has to waste time using Reflection to find and obtain the value.

Also, if you plan to move onto other languages, it's good practice to use strong-typing like in C++ and C# (with the exception of the var keyword, but that should be used when the type is obvious or irrelevant).

Originally Posted by master131

False. Using Strict On prevents unneccesary casting and binding during runtime which can improve the speed of code. When I used to code in VB.NET, I used to always enable it. Plus it makes your code more explicit and more understandable.

For example, if you omit the type of a variable or function, it will automatically assume that it's an Object and when you use it in functions that expect something else, the .NET runtime needs to unbox the value if it's a value type (Integer, Single, Short, etc) or cast it to something else. Not to mention when you access fields/properties using late binding the runtime has to waste time using Reflection to find and obtain the value.

Also, if you plan to move onto other languages, it's good practice to use strong-typing like in C++ and C# (with the exception of the var keyword, but that should be used when the type is obvious or irrelevant).

Yeah, thats what I meant, but its just mainly for the 'correct' way of writing code.

Lets use Option Strict!

Post a Reply

Similar Threads

Tags for this Thread