Discussion: Option Strict and VB functions

[wyrd]

I think Option Strict is a good thing, however there is one instance (with C#, I don't believe this is so with VB) where it doesn't make sense in my opinion, and that's the case of enums. Enums under the hood are nothing more then integers (or whatever other basic type you allow them to be), much like chars are nothing more then integers, so why can't they be used interchangably with the basic type in which they are created from (once again, looking at chars as an example) :confused:

 

Other then that I have no problems with it at all and am glad C# has it on by default. Aside from the obvious which was pointed out by others, it also makes your code a bit easier to read by other prorammers which may get their dirty little hands on it. :D

[Nerseus]

You can *sorta* use Enums interchangably with their base types (int for example), but you do have to Cast. At first, I was really bothered by this but now I don't mind. In fact, it's saved my behind a few times. Case in point, in VB6 you could interchangably use the enum or an Integer/Long. Unfortunately, that meant you had to manually check each value to ensure it was a proper Enum value before using it. I *hated* that - it usually meant creating two constants to define the upper/lower valid values for an Enum to keep the code "clean".

 

While you have to cast an enum to an int now, I think it promotes much safer (or "strict") coding. The only downside I've seen is forgetting to cast the enum when assigning to a variable declared as object - you'll get no warning but it's probably not what you want to do. For example, we define all system-dependent lookup values as enums so that we can easily find them in code. When using one of these enums in a DataSet (where each column's value is type object), you can put in the Enum itself without casting. If you try and send that DataSet to a Webservice, you'll get an error because the Enum doesn't exist on the other end (the serializer is nice enough to put the Enum in the DataSet as itself, not as an integer value).

 

Here's some old VB6 code, for those interested, that shows just how BAD Enums could be:

Public Enum Testing
   a = 1
   b = 2
   c = 3
End Enum
   
Private Sub Form_Load()
   Dim a As Testing
   
   a = Testing.b
   Debug.Print a

   a = 8
   Debug.Print a
   
   Test c
   Test 19
End Sub

Private Sub Test(TestVal As Testing)
   Dim enumVal As Testing
   
   enumVal = TestVal
   Debug.Print enumVal
End Sub

 

This prints:

2

8

3

19

 

Obviously, the 8 and the 19 should NEVER have been allowed to be assigned since the variables are explicitly defined to be of type Testing (the enum). Arggh.... shame on you, VB6.

 

-Nerseus

[Banjo]

I believe that the reason for being able to do that is to able to specify special values that you want to pass but do not want to be shown in the interface. I'm saying whether that's good or bad, but that is why its there.

[steved]

Option Strict really makes a great deal of sense. Removing it allows you (and your co-workers) to write code which can inadvertently cripple a program. Stability, code readability, and security are all seriously jeapordized when IDE and compiler features like Option Strict are left out.

 

It may just seem like a small thing (and particularly annoying for those who have used VB6 or equivalent pseudo-languages for years), but it is well worth it to know you will come out of the difficulties it presents a better programmer.

 

.steve

[Derek Stone]

Just in case anyone is interested...

 

You can turn Option Strict on by default for individual project types by adding the following line to the script file under \Visual Studio .NET\Vb7\VBWizards\ProjectType\Scripts\LocalizationCode\.

 

project.Properties("OptionStrict").Value = 1;

 

I've found this helpful, since my "memory chromosome" is lacking...