rachelreese's blog

I still can't believe that this isn't default behavior. If I was designing the language and someone complained that the change would break their apps, I'd kick them in the head.

The only reason I could think of that would break if short circuiting was on by default was if someone was so crazy that they wrote code like this:

If i > 5 Or DoSomethingReallyImportantThatMustRun = "I'm an idiot" Then ...

Since switching to C#, I've realized that I always use the short-circuiting versions of And and Or (&& and || which are the equivalents of AndAlso and OrElse). I think I've used the & operator once...and I can't think why I did it... :)

My advice, always use AndAlso and OrElse (or switch to C# and use && and || ;)...the short-circuiting operators are more effecient than their non-short-circuiting counterparts.

Yeah, as soon as I found out about AndAlso & OrElse, I couldn't even figure out why And and Or really existed. It seems so redundant.

Out of curiousity, did & and | exist in C? That was my last run-in with semi-colons and curly brackets, and I never even so much as thought to use them...

Nevermind, Darren said | exists in C in his post. :-)

The reason for this behavior in C and VB is really quite simple. | and & (And and Or) are BITWISE operators, although you can use them to test for true/false (because 1 & 1 = 1, but 1 & 0 != 0), you never should, because that sure as hell isn't what they are meant for. They are meant for doing stuff like:

if(flag & SOMEBITMASK != 0)
{
// do something
}

Where a simple && or || could not possibly do the trick, since they are logical operators and the result of "if(flag && SOMEBITMASK)" would turn out to be:

if(flag == TRUE)
{
if(SOMEBITMASK == TRUE)
{
// do something
}
}

Which is not the least bit what you wanted to do. So, both are very different.

The addition of AndAlso/OrElse was the most annoying change MS made for Beta 2. Pre-Beta 2 AND and OR were short circuiting operators. I wish they had implemented it as a new Option statement rather than adding 2 new operators. That way we could put
Option SloppyCode=On
at the top of our code if we didn't want to short circuit.

Another annoyance is the fact that they changed it (I think this was a beta1-beta2 change) so that array declarations ended on the number used so
Dim Bob(5) as String
gives you a 6 element string array. I'd rather have it give me an array with elements 0 through 4. Maybe we need an
Option CantHandleZeroBasedMath=On

Yah, unfortunately after Beta 1, it all went to hell, because some really high up VB people in the industry started bitching. It's really too bad, but oh well, that's history and even for it's short-comings it's still good, so wee-freakin'-haw! :D

I always use AndAlso and OrElse also :)

New keywords explained.

Grant Killian

Until .Net arrived I always wrote short-circuit'd code statements.

I would take the original example;
If myInteger=4 And myString=“Hello” then
CallFunction()
End If

And write;
If myInteger=4 Then
If myString=“Hello” then
CallFunction()
End If
End If

It always resulted in better performing code.

Regarding array declaration:

I agree that the array declarations "adding" an element is confusing at first. I was writing a serial communication program and the extra element was screwing things up.

I believe the reason they did it is because then you can use either 1-based arrays or 0-based arrays easily. That means all us 0-based people have to remember to declare the array with the index of the last element in parentheses, rather than the size.

Regarding AndAlso and OrElse:

I recently discovered these, after I wrote a whole program with And's and Or's everywhere. I don't think they are fully interchangeable. There are some situations where AndAlso is essential. For example:

If listbox.SelectedItem <> nothing AndAlso listbox.SelectedItem.ToString = "the item"

is an absolute must if you have Option Strict turned on, because if you don't, this will generate an exception if the first test is omitted or AndAlso is replaced with And (because you'll get a null reference exception on the "ToString")

Listbox behavior, in this respect, is quite annoying. If you start using AndAlso and OrElse from the beginning, you avoid a lot of problems like these if you suddenly switch to Strict = On (like I did).