Path: utzoo!attcan!uunet!ogicse!dali!brutus.cs.uiuc.edu!usc!cs.utexas.edu!asuvax!noao!arizona!sunquest!ggg
From: ggg@sunquest.UUCP (Guy Greenwald)
Newsgroups: comp.lang.c
Subject: Re: C style peeve and knowing the rules
Summary: Pedagogy
Message-ID: <2677@sunquest.UUCP>
Date: 26 Mar 90 16:00:53 GMT
References: <2205@osc.COM> <340018@hplvli.HP.COM> <19356@megaron.cs.arizona.edu> <894@dino.cs.iastate.edu>
Organization: Sunquest Information Systems, Tucson
Lines: 30

In article <894@dino.cs.iastate.edu>, hascall@cs.iastate.edu (John Hascall) writes:
> 
>    Operator precedence and associativity in C is quite complicated
>    and somewhat non-intuitive.  A few well-placed parentheses can
>    go a long way toward promoting readability and understanding,
>    even if they are not strictly necessary.[1]

For once, I agree with Robert J. Drabek. If you read his article carefully,
you'll see he's making a pedagogic point. A student who is required to use
the minimum number of parentheses will have to understand C's precedence
rules. After the student leaves his class, he's on his own, but as a 
teacher, Robert will have done his job.

As for the egregious

      a /= b ? c << 3 & g || f ? e || 2 + ++d & ~c : w : z;

the programmer should have broken it up into a separate series of simpler
expressions.

      a /= (b ? (
                  (((c << 3) & g) || f) ? (
                                            (e || ((2 + ++d) & ~c)) :
                                            w
                                          ) :
                  z
                )
           );

is not much of an improvement, in my opinion.