On Aug 19,  7:37pm, "Brian C. Grayson" wrote:
} Subject: Parentheses and KNF
}   While we're at it, the KNF doc (/usr/share/misc/style) gives
} the following as an example of an expression that shouldn't have
} any more parentheses than those strictly needed:
}         /*
}          * Unary operators don't require spaces, binary operators do. Don't
}          * use parenthesis 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;
} 
}   Can _anyone_ parse that in 5 seconds or less, or should
} the comment and the example be changed/updated?  :)

Definitely needs more parens!

On Aug 19,  9:08pm, "John F. Woods" wrote:
} Subject: Re: Parentheses and KNF

} (Myself, I would feel entirely justified parenthesizing that as
} 
}         a = ( (b->c[0] + ~d == (e || f)) || (g && h) ) ? i : (j >> 1);

maybe
         a = ( (b->c[0] + ~d == (e || f)) || g && h ) ? i : (j >> 1);

I try to avoid excessive use of parens when the meaning of the expression
is clear without them.  With too many parens, it's harder to figure out
which ones match up than it is to keep track of the operator precedences.

	a*b + c		better
	(a * b) + c	worse

On Aug 20,  3:16pm, "Michael K. Sanders" wrote:
} Subject: Re: Parentheses and KNF
} In message <199808202028.NAA11714@andare.fugue.com>, Ted Lemon writes:
} >
} >Hm.   I don't buy the idea that ) ) ever makes code more readable.
} >Maybe it's the font I'm using.
} 
} Maybe in Lisp, but even then I'd stick with )).

That's where I picked up this habit, but I generally only add the extra space
inside the innermost paren whose mate is on another line.  I'll sometimes
do this for the matching parens on one line if there are so many that it's
really difficult to match them up without counting or relying on computer
aids.

On Aug 20,  2:45pm, Wolfgang Solfrank wrote:
} Subject: Re: Parentheses and KNF
} While we are at this, I'd like to have the suggestion for continuation lines
} changed.  Currently continuation lines are supposed to be indented by four
} spaces independent of semantics.  In addition, while not explicitly stated,
} it is implied that the operator gets placed at the end of the previous line.
} I like to express the semantics more with the indentation, i.e. instead of:
} 
} 				dirbuf.d_fileno = cntobn(pmp,
} 				    pmp->pm_rootdirblk) * dirsperblk;
} 
} I like this more:
} 
} 				dirbuf.d_fileno = cntobn(pmp,
} 							 pmp->pm_rootdirblk)
} 						  * dirsperblk;
} 
} (This is an actual code snippet from msdosfs_vnops.c.)
} 
} This is, place the operator at the start of the continuation line (except
} for the comma separator); if lines are broken at one point, break it at all
} lower binding operators, too; and indent continuation lines to the point where
} the first operand at the same binding level in the previous line is.
} 
} IMHO this makes those expressions much easier to parse.  (And yes, I know
} that this wastes some of the valuable screen real estate.)

I also prefer number two, though I generally place the operator at the end
of the line.
	a = b +
	    c;

I could be convinced either way, though.


On Aug 20, 10:42pm, Hauke Fath wrote:
} Subject: Re: Parentheses and KNF
} At 21:41 Uhr +0200 20.08.1998, Skeelo wrote:
} >Ahh I find the first version easier to deal with than the second.
} 
} Strongly seconded, especially if we must keep tab8 indentation. (must we?)
} For printing as well as screen handling, linelength should be kept < 80
} chars, and with meaningful variable and function names the proposed scheme

Visually I prefer tabbing by 4 characters.  Plus tab8 pushes the code
to the right too quickly, expecially if you have a loop containing a few
levels of nested ifs, even without this continuation line convention.
It's especially bad if you also have long and nasty expressions on the
LHS
	SomePointer->thingy[0].whatever = ...
or long printf format strings.