Date: Thu, 28 Jan 1999 14:04:20 +1100 From: Peter Jeremy <peter.jeremy@auss2.alcatel.com.au> To: current@FreeBSD.ORG Subject: Re: btokup() macro in sys/malloc.h Message-ID: <99Jan28.135501est.40356@border.alcanet.com.au>
next in thread | raw e-mail | index | archive | help
Matthew Dillon <dillon@apollo.backplane.com> wrote:
>:style(9) should emphasize legibility and maintainability, rather than
>:minimizing the number of extraneous (from the compiler's perspective)
>:parenthesis.
> As far as parenthesis go, it's irrelevant because -Wall pretty much
> covers the most common mistakes.
I was thinking in terms of the parenthesis required as a result of the
operator precedences (from K&R), rather than gcc -Wall.
> If your code compiles without generating
> a warning, your parenthesization is in good shape.
Agreed.
> Braces and indentation and other purely visual effects are a different
> matter.
Agreed. I think style(9) errs on the side of too few braces as well.
My preference is for braces whenever you exceed 1 physical line rather
than 1 statement. eg
if (this &&
that) {
foo();
}
if (this) {
if (that)
a = b;
else
c = d;
}
Unfortunately (or maybe fortunately), gcc doesn't have an option to
warn you that your indentation doesn't doesn't match its parsing.
eg:
if (a)
if (b)
foo();
else
bar();
baz();
It would be nice if style(9) documented the options to give indent(1)
to match the `approved' layout convections. (This would reduce the
effort involved in importing large chunks of code).
Peter
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?99Jan28.135501est.40356>
