From owner-freebsd-current Fri Jan 29 02:46:44 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA28717 for freebsd-current-outgoing; Fri, 29 Jan 1999 02:46:44 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA28711 for ; Fri, 29 Jan 1999 02:46:41 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by nlsystems.com (8.9.1/8.8.5) with SMTP id KAA09325; Fri, 29 Jan 1999 10:49:13 GMT Date: Fri, 29 Jan 1999 10:49:12 +0000 (GMT) From: Doug Rabson To: Sheldon Hearn cc: Greg Lehey , current@FreeBSD.ORG Subject: Re: btokup().. patch to STYLE(9) (fwd) In-Reply-To: <92584.917604304@axl.noc.iafrica.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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