From owner-freebsd-current Fri Jan 29 12:06:05 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA04224 for freebsd-current-outgoing; Fri, 29 Jan 1999 12:06:05 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from octopus.originative.co.uk (originat.demon.co.uk [158.152.220.9]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA04159 for ; Fri, 29 Jan 1999 12:05:41 -0800 (PST) (envelope-from paul@originative.co.uk) From: paul@originative.co.uk Received: by octopus with Internet Mail Service (5.5.1960.3) id ; Fri, 29 Jan 1999 20:04:09 -0000 Message-ID: To: dfr@nlsystems.com, axl@iafrica.com Cc: grog@lemis.com, current@FreeBSD.ORG Subject: RE: btokup().. patch to STYLE(9) (fwd) Date: Fri, 29 Jan 1999 20:04:06 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > -----Original Message----- > From: Doug Rabson [mailto:dfr@nlsystems.com] > Sent: 29 January 1999 10:49 > To: Sheldon Hearn > Cc: Greg Lehey; current@FreeBSD.ORG > Subject: Re: btokup().. patch to STYLE(9) (fwd) > > > On Fri, 29 Jan 1999, Sheldon Hearn wrote: > > On Fri, 29 Jan 1999 20:01:23 +1030, Greg Lehey wrote: > > ... > > > 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) > You could just as easily make a case for if ((t % u - n % u) < (d % u)) the parens then draw your eye naturally to the central operator but anyhow.... I think this sums up the general problem with style(9) and also this thread. The style guide does not say anything definitive about how to parenthesize the above expression. What style(9) says, and it's been quoted many times already is "Don't use parentheses unless they're required for precedence or the statement is really confusing without them". ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Not this second bit, style(9) *ALLOWS* the use of extra parentheses when the programmer feels the statement would be really confusing without them. The whole argument is over what people consider to be "really confusing" and that is definately something down to the person doing the coding. In my mind, adding extra parens for readibility is a good thing and I fail to see where my opinion is in any way in conflict with style(9) since I only add them if I feel that the expression would be more confusing without them. I think people reading the above quote from style(9) and interpreting it as meaning we should be minimalist in our use of parens is misreading it. To be honest, style(9) as it stands is worthless since it has paragraphs such as the following in it "In general code can be considered ``new code'' when it makes up about 50% or more of the files[s] involved. This is enough to break precedents in the existing code and use the current style guidelines" Over time this can only lead to a mishmash of styles throughout the codebase. I disagree with this being acceptable practice, it's a cop-out which basically says, "we have a style guide that encapsulates how the current code looks but you're free to write in any style you want as long as you write enough of it". In the long run you may as well not bother with style(9), either there is a standard style or there isn't, a man page documenting current style without advocating continuing adherence is a rather pointless exercise. It think it's a mistake to allow programmers to veer away from a common style. Without consistency across the project it becomes difficult to maintain code, which is why KNF exists in the first place. Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message