AndAlso, OrElse and brackets

[Mike Ratcliffe]

We have been having a lively debate at work about whether or not we
should use brackets with conditionals that contain AndAlso. This is
because AndAlso has precedence over OrElse and I say that it makes
code more manageable if brackets are included.

False OrElse True AndAlso False will return False because AndAlso has
precedence over OrElse.

I say that this is better written as:
False OrElse (True AndAlso False)

What do you think?

 

[AMercer]

I agree with you - include the parentheses. More so with less often used
constructs, and more so with more complex expressions. Intent will be clear
to the new guy next year whose first assignment is making a mod to this code.

 

[Armin Zingler]

Am 22.03.2010 13:32, schrieb Mike Ratcliffe:

We have been having a lively debate at work about whether or not we
should use brackets with conditionals that contain AndAlso. This is
because AndAlso has precedence over OrElse and I say that it makes
code more manageable if brackets are included.

False OrElse True AndAlso False will return False because AndAlso has
precedence over OrElse.

I say that this is better written as:
False OrElse (True AndAlso False)

What do you think?

Agreeing with AMercer.

 

[Cor Ligthert[MVP]]

Mike,

This are question which completely depends on the knowledge of the users.

Some say parentheses make it easier to read, others say you would not put
things in code without a function, because then others become suspicious and
take time in it to examine why you did it and when they cannot find it, take
even more time.

However, personally I do it too, because I am simply to lazy to reminds me
what goes first especially in a not situation.

But to say that it is better, like I wrote, it is mainly because I'm lazy.

jmo

Cor

 

[Herfried K. Wagner [MVP]]

Am 22.03.2010 13:32, schrieb Mike Ratcliffe:

We have been having a lively debate at work about whether or not we
should use brackets with conditionals that contain AndAlso. This is
because AndAlso has precedence over OrElse and I say that it makes
code more manageable if brackets are included.

False OrElse True AndAlso False will return False because AndAlso has
precedence over OrElse.

I say that this is better written as:
False OrElse (True AndAlso False)

What do you think?

I don't like the brackets, but I'd suggest to use them because I doubt
that anybody who will work on the code is aware of the precendence rules
;-).

 

[Michel Posseth [MCP]]

i believe math rules are universal and that is the reasson thart using
brackets would give self documentation of the code , and that alone would
make it "good coding practice" in my homble opinion


HTH

Michel Posseth

 

[Mark Hurd]

We have been having a lively debate at work about whether or not we
should use brackets with conditionals that contain AndAlso. This is
because AndAlso has precedence over OrElse and I say that it makes
code more manageable if brackets are included.

I agree.

False OrElse True AndAlso False will return False because AndAlso has
precedence over OrElse.

I say that this is better written as:
False OrElse (True AndAlso False)

Bad example

(False OrElse True) AndAlso False = False
False OrElse (True AndAlso False) = False

and all expressions always need to be evaluated.

An example where it matters:
True OrElse True AndAlso False
(True OrElse True) AndAlso False = False
True OrElse (True AndAlso False) = True

and the expressions in the AndAlso in the second case are now not even
evaluated.

 

[Mike Ratcliffe]

We have a guy working here that is a brilliant developer, he is a
genius when it comes to dealing with extremely complex stuff. He
doesn't like the idea of adding "unnecessary brackets" as he says that
he never has to think twice when he looks at conditions. Personally I
don't see how using brackets in this situation could be a bad thing
but I guess he is pretty resistant to change.

I just find it fascinating that anybody would be opposed to such an
obvious improvement.

 

[Cor Ligthert[MVP]]

I agree with that guy, YOU want to change rules which are already more than
5000 years old.

Which does not mean that in complex situations I simply set some
parentheses.

Although I then mostly earlier break up the code with some more ifs.

But the guy is right.

Cor

We have a guy working here that is a brilliant developer, he is a
genius when it comes to dealing with extremely complex stuff. He
doesn't like the idea of adding "unnecessary brackets" as he says that
he never has to think twice when he looks at conditions. Personally I
don't see how using brackets in this situation could be a bad thing
but I guess he is pretty resistant to change.

I just find it fascinating that anybody would be opposed to such an
obvious improvement.

 

[Mark Hurd]

I agree with that guy, YOU want to change rules which are already more
than 5000 years old.

Which does not mean that in complex situations I simply set some
parentheses.

Although I then mostly earlier break up the code with some more ifs.

But the guy is right.

Cor

If you were talking about the basic arithmetic operators, */ +-, you'd
be right, brackets are almost always excessive.

But for And and Or I believe there have been computer languages that
have a precedence opposite that of Basic (however I couldn't find them
with a quick Google search).

When you think about it a bit And binding more tightly than Or /does/
make sense, but it isn't anywhere near as definite as multiplication and
addition (admittedly probably because we get taught BODMAS -- or one of
the variations described in Wikipedia -- very early in school, where as
Boolean algebra might not be formalised until Uni).

 

[Cor Ligthert[MVP]]

But for And and Or I believe there have been computer languages that
have a precedence opposite that of Basic (however I couldn't find them
with a quick Google search).

Most probably has somebody created that, but those had probably all a very
short lifetime.

The Or and And in Visual Basic have no short circuiting, which the OrElse
and AndAlso have.
This is rare in current program languages but that is not about this.