Picked up where we left off last time. Got last week’s assignment turned in. Have some homework due this week.Some discussion of requiring explicit variable declaration. There’s an option in Visual Basic to control variable declaration. By default, you don’t have to explicitly declare variables. This is convenient, up to the point at which you start making typos and new variables begin showing up. Basically, useful but dangerous. Professor suggests turning the explicit option on, so that declarations have to be made.
Similar discussion of strict type handling. If option strict is on, types will not be implicitly cast. Integers can’t be appended to strings without casting. Floats can’t have integers added without casting, etc. By default, option strict is turned off and this sort of thing is handled by the compiler’s logic. Professor recommends turning the option strict on.
I have mixed feelings about this sort of thing. Turning strict and explicit on both encourage good programming habits and make code more readable. On the other hand, VB is a high level language. The things you type are not directly related to the actions taken by the processor. Your commands go through whole levels of interpretation and compilation before they become usable. When you use a lower level language, it makes some sense to manage your variable types, because a declared integer is not the same beast as a floating point number, and you can save memory and prevent problems by managing them closely. Using a high level language and trying to obsess about type casts, however, seems a bit wrongheaded. People have largely switched to languages with neat features like implicit type conversion because those features are good, desirable things that make you life better.
Of course, it’s still good to know how things work. Prevents a great deal of magical thinking.
Now some talk about pseudocode. A very useful tool, pseudocode. Good for understanding things. Surprisingly hard to keep specific language elements out of pseudocode. Once you learn a language, you naturally start to visualize your solutions in terms of what you know how to do and how you prefer to do it. So, you start throwing in while loops and switches. Eventually, you’ve just written your program longhand, which defeats the purpose.
Some talk about if/then/else functionality. This is something VB does pretty well. Works about like I expect it to. Have to remember to place “end if” statements, though. In C, that was handled by brackets.
One thing that does throw me is comparison operators vs. assignment operators. In C, = was assignment and == was comparison. In VB, you use = for both. I keep looking for a different comparison operator, lest I assign my test value to my test variable and sabotage my conditional statements. Trained reflex.
Discussing the various logical operators. About what I expected; And, Or, Not. The important ones to pay attention to right now are the AndAlso operator, the OrElse operator, and the XOr operator, especially XOr.
AndAlso and OrElse essentially work like the And and Or operators, respectively. The difference is that they short-circuit the expression evaluation. If the first operand fulfills the criteria or invalidates it, the second operand is not evaluated. Easy enough.
XOr is the exclusive Or operator. Meaning, it returns true only when one operand evaluates as true and the other operand evaluates as false, not when both are true. That could be handy.