> -----Original Message-----
> From: Doug Rabson [mailto:d...@nlsystems.com]
> Sent: 29 January 1999 10:49
> To: Sheldon Hearn
> Cc: Greg Lehey; curr...@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 majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
