Discussion: Option Strict and VB functions

divil said:
Turn on Option Strict, always. It stops you doing bad things like mixing data types and not explicitly converting.
Click to expand...
We just had this discussion in my office and I think Option Strict is annoying for one reason: you can't 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.
 
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 it's 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 it's declared as a base class just as flexibly as if it were declared as the subclass, only of course you won't 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?
 
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
 
divil said:
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 it's going to be an instance of a subclass instead.
Click to expand...
abosutely? Why? If I have a derived class it'll 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 I've just not experienced yet?
 
It *does* work just like an interface in that scenario. As I said before, you don't have to cast it to run an overridden method on the base class.
 
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
 
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:
Visual Basic: 
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
 
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.
 
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
 
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\.

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

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