Prev: Class Design with Collection Classes
Next: MIME Messages
From: Michel Posseth [MCP] on 22 Mar 2010 16:58

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


"Mike Ratcliffe" <sabine.michael.ratcliffe(a)gmail.com> schreef in bericht
news:1693dfce-1557-4369-889c-c271c72a3bf6(a)m37g2000yqf.googlegroups.com...
> 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?

From: Mark Hurd on 23 Mar 2010 20:23
"Mike Ratcliffe" <sabine.michael.ratcliffe(a)gmail.com> wrote in message
news:1693dfce-1557-4369-889c-c271c72a3bf6(a)m37g2000yqf.googlegroups.com...
> 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.

--
Regards,
Mark Hurd, B.Sc.(Ma.) (Hons.)

From: Mike Ratcliffe on 24 Mar 2010 09:25
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.

On 24 Mar, 01:23, "Mark Hurd" <markh...(a)ozemail.com.au> wrote:
> "Mike Ratcliffe" <sabine.michael.ratcli...(a)gmail.com> wrote in message
>
> news:1693dfce-1557-4369-889c-c271c72a3bf6(a)m37g2000yqf.googlegroups.com...
>
> > 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.
>
> --
> Regards,
> Mark Hurd, B.Sc.(Ma.) (Hons.)

From: Patrice on 24 Mar 2010 10:02
Does he consume only his own code ?

I myself prefer to have them because when I read someone else code, if they
are not there, I tend to double check that the condition really makes sense
in case the guy who wrote the code made a mistake by omitting them ;-)

--
Patrice


"Mike Ratcliffe" <sabine.michael.ratcliffe(a)gmail.com> a �crit dans le
message de groupe de discussion :
c02e923a-7a10-41ec-b24f-d5d113418ed4(a)e7g2000yqf.googlegroups.com...
> 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.
>
> On 24 Mar, 01:23, "Mark Hurd" <markh...(a)ozemail.com.au> wrote:
>> "Mike Ratcliffe" <sabine.michael.ratcli...(a)gmail.com> wrote in message
>>
>> news:1693dfce-1557-4369-889c-c271c72a3bf6(a)m37g2000yqf.googlegroups.com...
>>
>> > 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.
>>
>> --
>> Regards,
>> Mark Hurd, B.Sc.(Ma.) (Hons.)
>
>

From: Cor Ligthert[MVP] on 25 Mar 2010 04:02
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

"Mike Ratcliffe" <sabine.michael.ratcliffe(a)gmail.com> wrote in message
news:c02e923a-7a10-41ec-b24f-d5d113418ed4(a)e7g2000yqf.googlegroups.com...
> 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.
>
> On 24 Mar, 01:23, "Mark Hurd" <markh...(a)ozemail.com.au> wrote:
>> "Mike Ratcliffe" <sabine.michael.ratcli...(a)gmail.com> wrote in message
>>
>> news:1693dfce-1557-4369-889c-c271c72a3bf6(a)m37g2000yqf.googlegroups.com...
>>
>> > 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.
>>
>> --
>> Regards,
>> Mark Hurd, B.Sc.(Ma.) (Hons.)
>
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Class Design with Collection Classes
Next: MIME Messages