Date: Fri, 29 Jan 1999 12:05:04 +0200 From: Sheldon Hearn <axl@iafrica.com> To: Greg Lehey <grog@lemis.com> Cc: current@FreeBSD.ORG Subject: Re: btokup().. patch to STYLE(9) (fwd) Message-ID: <92584.917604304@axl.noc.iafrica.com> In-Reply-To: Your message of "Fri, 29 Jan 1999 20:01:23 %2B1030." <19990129200123.I8473@freebie.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 29 Jan 1999 20:01:23 +1030, Greg Lehey wrote:
> > I can't imagine how unnecessary parens are going to improve
> > "readability" for anyone who knows his/her operator precedence.
>
> What about the others?
I'd like to know that people who don't know operator precedence are
leaving the kernel code alone, eh? :-)
> Remember, we're not talking about the writer now, we're talking about
> the reader, who in the general case is not the same person.
Operator precedence is not a matter of perspective. A different person,
who knows his or her operator precedence, will find the expression as
easy to read as the writer.
> Documentation is the castor oil of programming. Managers know it
> must be good because the programmers hate it so much.
I take this to mean "provide above your expression a comment that
explains what you're doing", not "clutter your expression with
unnecessary parens in case you've made a mistake that nobody will spot
because you haven't commented your code properly."
The reason I'm interested in this (now tiresome) thread is that I'd much
rather have to read
/*
* Bail out if the time left to next transaction is less than
* the duration of the previous transaction.
*/
if (t % u - n % u < d % u) {
than
if (((t % u) - (n % u)) < (d % u)) {
Giving folks the go-ahead to use parens as a form of documentation is
misguided and will end in tears. MHO.
Ciao,
Sheldon.
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?92584.917604304>