From: Randy Dunlap <randy.dunlap@oracle.com>
To: David Brownell <david-b@pacbell.net>
Cc: torvalds@linux-foundation.org, linux-kernel@vger.kernel.org,
khali@linux-fr.org, akpm@linux-foundation.org
Subject: Re: [PATCH] CodingStyle: Printing numbers in parentheses is fine
Date: Sat, 29 Sep 2007 15:51:01 -0700 [thread overview]
Message-ID: <20070929155101.43079713.randy.dunlap@oracle.com> (raw)
In-Reply-To: <20070929223015.7F052236A50@adsl-69-226-248-13.dsl.pltn13.pacbell.net>
On Sat, 29 Sep 2007 15:30:15 -0700 David Brownell wrote:
> > > > Let's kill it, please. (i.e., ACK)
> > >
> > > But ... why? What value could needless parens provide?
> >
> > Who says that needless parens could provide value?
>
> Jean, which is why he submitted the patch.
> You, implicitly, by acking a patch saying those parens are bad.
> But not me ... I don't think this patch is merge-worthy.
Thanks for clearing that up. Yes, you did have me confused.
Sure, if something is needless, it doesn't provide value.
So we disagree that some parens are needless. OK.
> > > "Yet Another Subtle And Hard To Fix Source Of Bloat" is
> > > not a plus.
> >
> > ISTM that we agree.
>
> Evidently not, since removing it would promote such bloat.
> Explicitly removing disapproval is a form of approval...
>
>
> > > I'd kind of think a change like this should have some
> > > positive motivation.
> >
> > "Me, I agree that numbers in parens don't usually make sense for
> > kernel messages."
> >
> > It's too trivial to be included in CodingStyle.
>
> So the reason to remove that guideline, and thereby encourage
> proliferation of needless parens, is ... that some OTHER way
> to get rid of them is working?
Andrew listed some cases where parens make sense. He didn't say
(and I don't say) [oops, parens] that they always make sense,
but the statement in CodingStyle is too strict. Sometimes they
make sense.
> I would agree that line could be improved to say that messages
> should not be needlessly large. Excess parens are one example;
> wordiness is another (including printing 8 bit fields as 0x%08x),
> and I'm sure there are more.
---
~Randy
next prev parent reply other threads:[~2007-09-29 22:53 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-29 10:25 [PATCH] CodingStyle: Printing numbers in parentheses is fine Jean Delvare
2007-09-29 10:51 ` Andrew Morton
2007-09-29 17:19 ` David Brownell
2007-09-29 18:29 ` Randy Dunlap
2007-09-29 18:53 ` David Brownell
2007-09-29 20:13 ` Randy Dunlap
2007-09-29 22:30 ` David Brownell
2007-09-29 22:51 ` Randy Dunlap [this message]
2007-09-29 22:55 ` Måns Rullgård
2007-09-30 10:28 ` Jean Delvare
2007-09-30 2:18 ` Valdis.Kletnieks
2007-09-30 10:11 ` Jean Delvare
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070929155101.43079713.randy.dunlap@oracle.com \
--to=randy.dunlap@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=david-b@pacbell.net \
--cc=khali@linux-fr.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.