that line was confusing enough for me...
I think style (9) needs to be relaxed a bit on that 
I think the bit about parns just intriduces bug "opportunities"
and certainly the bit about braces DEFINATLY introduces bugs.

Braces and parens allow humans to understand the and read the code with
less chance of misunderstanding. It doesn't help the compiler at all to
remove them and it does allow people like me (who can never get the
precedence write in different languages) to be sure of what they are
looking at.


"unambiguous to the compiler and unambiguous to the casual reader
are not the same thing". I would certainly have added the parens.

I always add then when there ar emore than two operands and one of
<< >> && == || (cast) & | 

in fact I personally tend to disambiguate any operation more complicated
than a string of additions.

julian


On Wed, 27 Jan 1999, John Polstra wrote:

> In article <199901272128.naa56...@apollo.backplane.com>,
> Matthew Dillon  <dil...@apollo.backplane.com> wrote:
> >     Is this parenthesization correct ?
> > 
> >     OLD
> > 
> > #define btokup(addr)    (&kmemusage[(caddr_t)(addr) - kmembase >> 
> > PAGE_SHIFT])
> > 
> >     NEW
> > 
> > #define btokup(addr)    (&kmemusage[((caddr_t)(addr) - kmembase) >> 
> > PAGE_SHIFT])
> 
> The added parentheses don't make any difference, semantically.  This
> change probably wouldn't meet the criteria spelled out in style(9):
> 
>      Unary operators don't require spaces, binary operators do. Don't use
>      parentheses unless they're required for precedence, or the statement is
>      really confusing without them.
> 
>              a = b->c[0] + ~d == (e || f) || g && h ? i : j >> 1;
>              k = !(l & FLAGS);
> 
> John
> -- 
>   John Polstra                                               j...@polstra.com
>   John D. Polstra & Co., Inc.                        Seattle, Washington USA
>   "Nobody ever went broke underestimating the taste of the American public."
>                                                             -- H. L. Mencken
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-current" in the body of the message
> 


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Reply via email to