Re: [ros-dev] [ros-diffs] [ion] 52596: [NTDLL]: More attempts at fixing up the loader, this time in the PE side of things.

[Aleksey Bragin]

-----Original Message----- 
From: ion(a)svn.reactos.org
Sent: Sunday, July 10, 2011 6:14 AM
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [ion] 52596: [NTDLL]: More attempts at fixing up the 
loader, this time in the PE side of things.

Author: ion
Date: Sun Jul 10 02:14:29 2011
New Revision: 52596

     /* Check if we got at least one */
-    if (BoundEntry || ImportEntry)
+    if ((BoundEntry) || (ImportEntry))

Could you enlighten me why do you add these redunandant braces?

WBR,
Aleksey.

[Alex Ionescu]

Because that's the convention I keep trying to make you enforce. It avoids confusion.

Yes, you will now argue 10 scenarios where this doesn't matter (such as below).

And by doing so, you will have proven my point:

1) You can avoid using (() || ()) if you know the 10 exceptions and operator precedence by
heart. (Aleksey Method)
or
2) You can always use (() || ()) and never have to worry about anything (in this context).
(The Sane Method).

If you'd like to enforce a coding style that requires people knowing K&R by heart,
go ahead, but I won't subscribe to it. KISS.

--
Best regards,
Alex Ionescu

On 2011-07-10, at 1:01 PM, Aleksey Bragin wrote:

>   
>  
>  -----Original Message----- From: ion(a)svn.reactos.org
>  Sent: Sunday, July 10, 2011 6:14 AM
>  To: ros-diffs(a)reactos.org
>  Subject: [ros-diffs] [ion] 52596: [NTDLL]: More attempts at fixing up the loader, this
> time in the PE side of things.
>  
>  Author: ion
>  Date: Sun Jul 10 02:14:29 2011
>  New Revision: 52596
>  
>     /* Check if we got at least one */
>  -    if (BoundEntry || ImportEntry)
>  +    if ((BoundEntry) || (ImportEntry))
>  
>  Could you enlighten me why do you add these redunandant braces?
>  
>  WBR,
>  Aleksey. 
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Timo Kreuzer]

Am 12.07.2011 00:52, schrieb Alex Ionescu:
>   Because that's the convention I keep trying to
> make you enforce. It avoids confusion.
>
>  Yes, you will now argue 10 scenarios where this doesn't matter (such as below).
>
>  And by doing so, you will have proven my point:
>
>  1) You can avoid using (() || ()) if you know the 10 exceptions and operator precedence
> by heart. (Aleksey Method) 
But there is no operator involved in
"(BoundEntry)", so you don't need 
to know any operator precedence.

>   or
>  2) You can always use (() || ()) and never have to worry about anything (in this
> context). (The Sane Method). 
In that case I also suggest using
SomeVariable = (OtherVariable);
return (Status);
if ((x == 2)) return;
SomePointer = &(Structure);
(SomePointer)->Member = (0);

>  >     /* Check if we got at least one */
> > -    if (BoundEntry || ImportEntry)
> > +    if ((BoundEntry) || (ImportEntry))
> > 
Sorry for being sarcastic, but I just had to do this. You're literally 
asking for it :)

I hope it won't lead to the introduction of something like
#define MY_CONSTANT sizeof(FOO) + 20


Regards,
Timo

[Ged Murphy]

Timo Kreuzer wrote:

> >   1) You can
> > avoid using (() || ()) if you know the 10 exceptions and 
> >  operator precedence by heart. (Aleksey Method) 
>  But there is no operator involved
> in "(BoundEntry)", so you don't need to 
know any operator precedence.

There is really, but it's just hidden in the language.
if ((BoundEntry != 0) || (ImportEntry != 0))


I'm a fan of parenthesis, I can't think of a situation when their use makes
code less clear or harder to read.

Ged.

[Elvis]

I do think Alex is talking about expressions such as (test1 & 55) == 
((test2 & test3) | 110) for example.

Or even (test1 == 44) && (test2 == 110) too.

I do agree the (()||()) style convention can avoid confusion for such 
expressions.

On 7/12/11 22:44, Timo Kreuzer wrote:
>   Am 12.07.2011 00:52, schrieb Alex Ionescu:
> >   Because that's the convention I keep trying
> > to make you enforce. It
> >  avoids confusion.
> >
> >  Yes, you will now argue 10 scenarios where this doesn't matter (such
> >  as below).
> >
> >  And by doing so, you will have proven my point:
> >
> >  1) You can avoid using (() || ()) if you know the 10 exceptions and
> >  operator precedence by heart. (Aleksey Method) 
>  But there is no operator involved
> in "(BoundEntry)", so you don't need
>  to know any operator precedence.
>
> >   or
> >  2) You can always use (() || ()) and never have to worry about
> >  anything (in this context). (The Sane Method). 
>  In that case I also suggest using
>  SomeVariable = (OtherVariable);
>  return (Status);
>  if ((x == 2)) return;
>  SomePointer = &(Structure);
>  (SomePointer)->Member = (0);
>
> >  > /* Check if we got at least one */
> > > - if (BoundEntry || ImportEntry)
> > > + if ((BoundEntry) || (ImportEntry))
> > > 
>  Sorry for being sarcastic, but I just had to do this. You're literally
>  asking for it :)
>
>  I hope it won't lead to the introduction of something like
>  #define MY_CONSTANT sizeof(FOO) + 20
>
>
>  Regards,
>  Timo
>
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev