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.
"Raterus" <ra*****@spam.o rg> wrote in message
news:%2******** ********@TK2MSF TNGP11.phx.gbl. ..
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
"Raterus" <ra*****@spam.o rg> wrote in message
news:%2******** ********@TK2MSF TNGP11.phx.gbl. ..
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]]

"Raterus" <ra*****@spam.o rg> wrote in message
news:%2******** ********@TK2MSF TNGP11.phx.gbl. ..

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:
"]"Raterus" <ra*****@spam.o rg> wrote in message

news:%2******** ********@TK2MSF TNGP11.phx.gbl. ..

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:f21cad243 1]

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.***@enough.s pam> wrote in message
news:uP******** ******@TK2MSFTN GP12.phx.gbl...

"Raterus" <ra*****@spam.o rg> wrote in message
news:%2******** ********@TK2MSF TNGP11.phx.gbl. ..

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.

[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.***@enough.s pam> wrote in message
news:uP******** ******@TK2MSFTN GP12.phx.gbl...

"Raterus" <ra*****@spam.o rg> wrote in message
news:%2******** ********@TK2MSF TNGP11.phx.gbl. ..

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.

[Jeff Johnson [MVP: VB]]

"Bob" <no****@nowhere .com> wrote in message
news:Os******** ******@tk2msftn gp13.phx.gbl...

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

"Bob" <no****@nowhere .com> wrote in message
news:Os******** ******@tk2msftn gp13.phx.gbl...

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.***@enough.s pam> wrote in message
news:uP******** ******@TK2MSFTN GP12.phx.gbl...

"Raterus" <ra*****@spam.o rg> wrote in message
news:%2******** ********@TK2MSF TNGP11.phx.gbl. ..

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.