AndAlso & OrElse

[Raterus]

I kinda just stumbled across these operators, they seem great, as you can forget the second expression depending on the result of the first, but are there any cons to using these?

From my viewpoint it seems I can pretty much to a find / replace on my existing code and pick up a performance boost, but something seems fishy that I really never see other people using these!

Thanks for any insight!
--Michael

 

[Cor Ligthert]

Raterus,

No consequences at all.

Only it looks so strange that most people forget it.

Cor

I kinda just stumbled across these operators, they seem great, as you can
forget the second expression depending on the result of the first, but are
there any cons to using these?

From my viewpoint it seems I can pretty much to a find / replace on my
existing code and pick up a performance boost, but something seems fishy
that I really never see other people using these!

 

[Jared]

My two cents - I think they are great operators and I use them all the time.
Like yourself, I stumbled upon them, and was a little cautious at first. I
believe people don't use them because they don't really know they exist.


I kinda just stumbled across these operators, they seem great, as you can
forget the second expression depending on the result of the first, but are
there any cons to using these?

From my viewpoint it seems I can pretty much to a find / replace on my
existing code and pick up a performance boost, but something seems fishy
that I really never see other people using these!

Thanks for any insight!
--Michael

 

[Carl Tribble]

The con is if the logic in your IF statement depends on all the conditions
being tested.

-Carl


I kinda just stumbled across these operators, they seem great, as you can
forget the second expression depending on the result of the first, but are
there any cons to using these?

From my viewpoint it seems I can pretty much to a find / replace on my
existing code and pick up a performance boost, but something seems fishy
that I really never see other people using these!

Thanks for any insight!
--Michael

 

[Jeff Johnson [MVP: VB]]

I kinda just stumbled across these operators, they seem great, as you can
forget the second expression depending on the result of the first, but are
there any cons to using these?

Interesting you shouild mention you just "stumbled across" them, because
they were touted as a new feature of VB.NET. Finally VB got true
short-ciruiting. Perhaps they weren't touted loudly or perhaps you weren't a
VB6 person and therefore never looked into the "new features" news.

The classic example of the main con to using these operators is when you do
something stupid like change the state of your application during a test. In
VB, that would basically mean that your If clause would have to contain a
function call as one of its (second or later) tests and that function call
would "do something," like changing the value of a variable, as opposed to
just testing and returning a result. This is generally considered bad
programming practice anyway, so there is virutally no down side to these
operators.

 

[David Anton]

Jeff Johnson [MVP: VB]wrote:

I kinda just stumbled across these operators, they seem great, as you can
forget the second expression depending on the result of the first, but are
there any cons to using these?

Interesting you shouild mention you just "stumbled across" them,
because
they were touted as a new feature of VB.NET. Finally VB got true
short-ciruiting. Perhaps they weren't touted loudly or perhaps you
weren't a
VB6 person and therefore never looked into the "new features" news.

The classic example of the main con to using these operators is when
you do
something stupid like change the state of your application during a
test. In
VB, that would basically mean that your If clause would have to
contain a
function call as one of its (second or later) tests and that function
call
would "do something," like changing the value of a variable, as
opposed to
just testing and returning a result. This is generally considered bad
programming practice anyway, so there is virutally no down side to
these
operators.[/quote:f21cad2431]

They were loudly touted when the operators were still "And" and "Or".
When many old-school VB programmers protested that their 'side-effect'
style of coding would be circumvented, so Microsoft relented and kept
"And" and "Or" behaving as in VB6, i.e., no short-circuiting. Then
the modern programmers protested that they wanted the short
circuiting, so Microsoft relented and added back short circuiting,
but as "AndAlso" and "OrElse" to try to keep everyone happy. (a
classic case illustrating why VB is like it is today).

 

[Bob]

I got into an argument with someone from MS over why they didn't make
short-circuiting logical operators the default so you didn't need the
longer-to-type, rather goofy-sounding AndAlso/OrElse. They said it would
"break existing code". Yet this rings false to me; when they first released
DotNet they didn't *have* any existing code. And even if there was any, the
only things that would break deserved to break. Or throw an autoreplace
feature in the useless Upgrade Wizard. I can think of no good reason
whatsoever to create code that depends on non-short-circuiting logical
operators. Haven't all languages (aside from pre-NET VB) short-circuited
since the creation of computers? Now that they set it one way, though, we're
probably going to have to live with this (IMHO) asinine VB "feature"
forever.

Bob

 

[Jeff Johnson [MVP: VB]]

I got into an argument with someone from MS over why they didn't make
short-circuiting logical operators the default so you didn't need the
longer-to-type, rather goofy-sounding AndAlso/OrElse. They said it would
"break existing code". Yet this rings false to me; when they first released
DotNet they didn't *have* any existing code. And even if there was any, the
only things that would break deserved to break. Or throw an autoreplace
feature in the useless Upgrade Wizard. I can think of no good reason
whatsoever to create code that depends on non-short-circuiting logical
operators. Haven't all languages (aside from pre-NET VB) short-circuited
since the creation of computers?

Many languages have different operators for Boolean operations vs. bitwise
operations, for example C[++/#]'s | and ||, and & and &&. VB did not, until
now. I don't have a problem with the new names.

 

[Cablewizard]

heh, if you search around you will find some other rants on this subject. The
big thing came down to separating the bit-wise and logical operators. In the
early betas, they implemented the BitAnd, BitOr, etc. to replace the old And,
Or, and instead implement those as true Logical operators as they are most
commonly used. However, in the end they gave in to whining from old school VB
programmers (and newbie's who don't know better yet) who have come to rely on
the oftentimes too flexible and vague stuff VB would let you get away with. So
they removed the explicit bit-wise operators and kept them as And/Or/etc. So
even though you are using them as logical, they are really bit-wise. This still
required the addition of the short-circuit operator AndAlso/OrElse.

Personally, I would have much preferred the separation of the operators, and I
know I'm not alone. However, in the end I think we were in the minority.

Gerald

 

[Andy Becker]

I kinda just stumbled across these operators, they seem great, as you can forget the second
expression depending on the result of the first, but are there any cons to

using these?

Only their obscurity, I guess.

Personally, I use them WAY more than the regular versions. Almost
exclusively, in fact. I might even argue that they should be the default
behavior, same as Bob. I do have a number of cases where evaluating both
sides is desirable, but not very many!

I can understand the MS position on backward compatibility, since before
VB.NET there was VB6, and no shortcut operators. I guess that is the
compatibility they were concerned about. The "feature" dates all the way
back to Dartmouth BASIC - doesn't have much to do with MS, since Bill was in
diapers at the time.

I'm not able to think of a single con against their use.

Best Regards,

Andy

 

[Guest]

I got into an argument with someone from MS over why they didn't make

short-circuiting logical operators the default so you didn't need the
longer-to-type, rather goofy-sounding AndAlso/OrElse. They said it would
"break existing code". Yet this rings false to me; when they first released
DotNet they didn't *have* any existing code.

Try to tell that to all the people porting VB6 code. (Just let me get my flame-proof suit on first.)

 

[Bob]

If MS had made AndAlso/OrElse the non-short-circuiting logical operators, it
would have been simply a question of auto-replacement either manually or
through the upgrade wizard.

But really, most VB6 projects of any significant complexity are junk simply
because there are so many fundamental things missing in the language. IMHO
it all begs to be rewritten.

Bob

 

[Jonathan Allen]

I have to admit, I would rather rewrite it by hand than try to use the
upgrade wizard.