Traditionally, Visual Basic has had permissive semantics; that is, the Visual Basic language, in general, does not require explicit syntax to be used when performing operations that might not be optimally efficient (for example, late binding) or that might fail at run time (for example, narrowing conversions). Although permissive semantics simplifies learning the Visual Basic language, it can hamper large-scale application development by allowing coding errors to slip by undetected. Visual Basic .NET offers the option of enforcing strict semantics during compilation.
Using Option Strict On means that the following would cause a compile time error:
- Narrowing conversions without an explicit cast operator.
- Late binding.
- Operations on type Object other than =, <>, TypeOf...Is, and Is.
- Omitting the As clause in a declaration.
This is a good thing.
Clemens Vasters of Newtelligence once said:
"It turns out that a major poor performance reason in Visual Basic.NET is that it has Option Strict off and C# has it on. Turning on Option Strict increases performance by around 30 to 70%.
There is nothing like "Option Strict" in C# as it is strict on types by default and that's non-negotiable :) "
There is only a single good reason to turn "Option Strict" off in Visual Basic .NET and that's late binding to COM objects through System.Object for any COM object that only has either
- only a dispinterface, or
- no complete type-library
For these cases, VB.NET is much more productive, because it'll autogenerate all required Reflection code under the hood.
And just because of the invisible, huge, auto-generated code and because of the VB6 developer's habit of ""Dim obj As Object"", the ""Option Strict"" the ""Option Strict"" should be switched ""on"" for all projects as a development policy and the isolated cases mentioned above should be quarantined in dedicated assemblies providing a wrapper around the COM objects in question.
Late binding of that sort should commonly not be necessary for .NET objects in business code (and it never should have been for COM); that's what interfaces are for.
Invoking objects through Reflection (or IDispatch for that matter) is always substantially slower than direct, early bound calls.