Date: Fri, 29 Jan 1999 00:47:49 -0500 From: Christopher Masto <chris@netmonger.net> To: current@FreeBSD.ORG Subject: Re: btokup().. patch to STYLE(9) (fwd) Message-ID: <19990129004749.A8899@netmonger.net> In-Reply-To: <199901290439.VAA03999@mt.sri.com>; from Nate Williams on Thu, Jan 28, 1999 at 09:39:36PM -0700 References: <199901290326.OAA22743@godzilla.zeta.org.au> <19990128230223.A1973@netmonger.net> <199901290439.VAA03999@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jan 28, 1999 at 09:39:36PM -0700, Nate Williams wrote:
> > Encouraging unreadable code is something I find highly questionable.
>
> I find the KNF style highly readable. As a matter of fact, I find the
> extra parentheses *often* to be a bunch of noise.
>
> And, as Bruce implied, if you don't know your precedence rules, you
> shouldn't be doing kernel programming.
Then either delete the style guide or write "DO NOT READ THIS UNLESS
YOU ARE AN APPROVED KERNEL PROGRAMMER" at the top.
Look, I program mainly in perl. I know the difference between
readability and noise. I know when it works just fine but it's making
trouble for those who come after you. And I know the difference
between a clever hack and a critical piece of production code.
Programming, particularly for a widely-used piece of critical system
software, should not be centered on showing off your incredible
prowess with precedence rules. Don't put "unnecessary" parens and
braces in your code if you don't want to. But if someone feels that
an expression is complicated enough to deserve giving the next person
to look at it a few hints as to its intended order of operations, then
please don't say they're not allowed to do so.
Even the great Berkeley gods have made mistakes. Anything that helps
avoid those mistakes, including -Wall, or extra parens and braces just
to make it more obvious what you're doing, is a good thing. It means
that FreeBSD will have fewer errors, fewer panics, and bugs will be
found more quickly.
Correct software is becoming an endangered species these days. When a
proposal is made that has no effect other than to allow a tiny bit of
freedom in the direction of enhanced correctness and maintainability,
please don't stand in the way.
As for noise, there are situations where excess punctuation is just
noise, and there are situations that benefit from more than the bare
minumum of decorations. Anyone doing kernel programming ought to know
the difference, just as they ought to know their precedence rules.
And there's always peer review for mere mortals who actually still
have peers.
I end with someone else's style guide, if only because of my evil streak:
o Just because you CAN do something a particular way
doesn't mean that you SHOULD do it that way.
[...]
Along the same lines, just because you CAN omit
parentheses in many places doesn't mean that you ought
to:
return print reverse sort num values %array;
return print(reverse(sort num (values(%array))));
When in doubt, parenthesize. At the very least it
will let some poor schmuck bounce on the % key in vi.
Even if you aren't in doubt, consider the mental
welfare of the person who has to maintain the code
after you, and who will probably put parentheses in
the wrong place.
--
Christopher Masto Director of Operations NetMonger Communications
chris@netmonger.net info@netmonger.net http://www.netmonger.net
"Good tools allow users to do stupid things." -- Clay Shirky
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?19990129004749.A8899>