David Young writes:

> On Sun, Jul 17, 2005 at 11:37:57PM +1200, Dave Sainty wrote:
> > Roland Illig writes:
> > 
> > > > +	if (kill(kp->p_pid, signum) == -1) {
> > > > +		if (errno == ESRCH)
> > > > +			/*
> > > > +			 * The process disappeared between us matching
> > > > +			 * it and us signalling it.  Return 0 to
> > > > +			 * indicate that the process should not be
> > > > +			 * considered a match.
> > > > +			 */
> > > > +			return 0;
> > > 
> > > Could you please but braces around the comment and the return? (twice)
> > 
> > Style says "Don't add braces that aren't necessary except in cases
> > where there are ambiguity or readability issues.".  It's probably open
> > to interpretation whether this case is an ambiguity or readability
> > issue :)
> 
> Usually I take it for granted that programmers are going to read code
> according to "Gestalt rules" of visual layout, not syntax, because they're
> people, not parsers.  Consecutive lines of code that all start in the
> same column will be read and edited as a "block," curly braces or not.
> If you code a "block" (Gestalt rules) as a "block" (parser rules), then
> you're going to save a fellow programmer-person a cursing fit later when
> they add a line to that "block."
> 
> That said, my recommendation is to put curly braces on that thar code,
> or else to move the comment outside of the if-statement.

I think I'll go with your second suggestion because the comment looks
pretty cramped at that level anyway.  My usual non-KNF style is 2
space indentation, so I'm used to having plenty of horizontal space to
work with.

I guess it's just my habit, but something looks strange to me with
braces around it - like I've misread the code or something because I
only read a single statement and a (relatively) short comment.

But no matter :)