Discussion: Option Strict and VB functions

[quwiltw]

Originally posted by divil
Turn on Option Strict, always. It stops you doing bad things like mixing data types and not explicitly converting.

We just had this discussion in my office and I think Option Strict is annoying for one reason: you cant treat a derived class the same as a base class without casting. In my opinion, you should be able to manipulate derived classes using a reference to the base class in much the same way you would an interface.

 

[Divil]

In what respect? If you have a variable declared as a base class then you absolutely should have to cast it if in one circumstance you know its going to be an instance of a subclass instead. If it were going to be a subclass all the time, presumably it would be declared that way.

You can certainly manipulate a variable if its declared as a base class just as flexibly as if it were declared as the subclass, only of course you wont have access to the subclass-specific members. If you call a method on it which has been overridden, the overriding method still gets called.

Maybe I misunderstood your argument?

 

[Nerseus]

Strict != Simpler Coding

I still prefer strict (the only way to go in C#). I used to get aggravated at not being able to use Enums as ints without casting, but I got over my issues and learned to do it the "right" way. Of course, "right" is a per-user setting (or per-office in some installations )

-Nerseus

 

[quwiltw]

Originally posted by divil
In what respect? If you have a variable declared as a base class then you absolutely should have to cast it if in one circumstance you know its going to be an instance of a subclass instead.

abosutely? Why? If I have a derived class itll always have the base classes methods available, so why should I have to cast it? It should work just like an Interface in my opinion, just like C++ and Java. Is this your personal preference or have you a situation that would break that Ive just not experienced yet?

 

[Divil]

It *does* work just like an interface in that scenario. As I said before, you dont have to cast it to run an overridden method on the base class.

 

[wyrd]

I think Option Strict is a good thing, however there is one instance (with C#, I dont believe this is so with VB) where it doesnt make sense in my opinion, and thats 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 cant they be used interchangably with the basic type in which they are created from (once again, looking at chars as an example)

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.

 

[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 dont mind. In fact, its 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 Ive seen is forgetting to cast the enum when assigning to a variable declared as object - youll get no warning but its 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 columns value is type object), you can put in the Enum itself without casting. If you try and send that DataSet to a Webservice, youll get an error because the Enum doesnt exist on the other end (the serializer is nice enough to put the Enum in the DataSet as itself, not as an integer value).

Heres 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. Im saying whether thats 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;

Ive found this helpful, since my "memory chromosome" is lacking...