Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 29 Jan 1999 10:49:12 +0000 (GMT)
From:      Doug Rabson <dfr@nlsystems.com>
To:        Sheldon Hearn <axl@iafrica.com>
Cc:        Greg Lehey <grog@lemis.com>, current@FreeBSD.ORG
Subject:   Re: btokup().. patch to STYLE(9) (fwd) 
Message-ID:  <Pine.BSF.4.01.9901291044130.95594-100000@herring.nlsystems.com>
In-Reply-To: <92584.917604304@axl.noc.iafrica.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 29 Jan 1999, Sheldon Hearn wrote:

> 
> 
> 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? :-)

I am a kernel developer.  I also sometimes forget some of the precedence
rules.  Often enough that I use strict parenthesising when I use those
operators.

> 
> > 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.

I don't agree.  If you have to stop and think about the stupid precedence
rules three times in an expression, the expression is too complicated and
should be simplified.

> 
> >   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)) {

This is a strawman.  The original expression is perfectly fine (by my
rules).  One could make a case for:

	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.

I don't agree, obviously.

--
Doug Rabson				Mail:  dfr@nlsystems.com
Nonlinear Systems Ltd.			Phone: +44 181 442 9037



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?Pine.BSF.4.01.9901291044130.95594-100000>