From: Benny Halevy <bhalevy@panasas.com>
To: Arnaldo Carvalho de Melo <acme@redhat.com>,
Christoph Hellwig <hch@infradead.org>,
Andy Whitcroft <andyw@uk.ibm.com>,
Christer Weinigel <christer@weinigel.se>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] teach checkpatch.pl about list_for_each
Date: Thu, 03 Jan 2008 17:17:29 +0200 [thread overview]
Message-ID: <477CFC89.1020409@panasas.com> (raw)
In-Reply-To: <20080103123036.GB29523@ghostprotocols.net>
On Jan. 03, 2008, 14:30 +0200, Arnaldo Carvalho de Melo <acme@redhat.com> wrote:
> Em Thu, Jan 03, 2008 at 12:26:10PM +0000, Christoph Hellwig escreveu:
>> On Thu, Jan 03, 2008 at 11:10:58AM +0000, Andy Whitcroft wrote:
>>> We have had some stabs at changing this, but no consensus was reached on
>>> whether it was a "for" or a "function". My memory is of there being
>>> slightly more "without a space" tenders than the other and so it has not
>>> been changed. This thread also seems so far to have not really
>>> generated a concensus. So I would tend to leave things as they are.
>>>
>>> A third option might be to accept either on *for_each* constructs.
>>> That might tend to lead to divergance. Difficult. However, also see my
>>> later comments on "style guide".
>> Pretty much all core code uses list_for_each_entry( so new code should
>> follow that example.
>
> Agreed, CodingStyle is not about mindless consistency such as "for (" is
> the right thing, so "list_for_each (" is consistent with it, it is about
> codifying practice contributors got used to over the years.
>
Why mindless?
Coding style is also about giving the coding language logic a graphical
representation. Following a convention that flow control keywords
such as "if", "for", or "while" are distinguished from function calls
by use of a space after the keyword really helps the code readability
regardless of how people used to code it in the past...
The for_each_* macros are clearly not function calls but rather translate
to for () flow control constructs hence they should follow the same convention.
FWIW, I think that changing the existing convention is worth it in this case.
Benny
> - Arnaldo
next prev parent reply other threads:[~2008-01-03 15:17 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-02 12:03 [PATCH] teach checkpatch.pl about list_for_each Christer Weinigel
2007-12-02 13:24 ` Arnaldo Carvalho de Melo
2007-12-02 19:47 ` Valdis.Kletnieks
2008-01-03 11:10 ` Andy Whitcroft
2008-01-03 12:26 ` Christoph Hellwig
2008-01-03 12:30 ` Arnaldo Carvalho de Melo
2008-01-03 15:17 ` Benny Halevy [this message]
2008-01-03 23:12 ` Christer Weinigel
2008-01-03 11:23 ` pHilipp Zabel
2008-01-03 12:34 ` Tomas Carnecky
2008-01-03 23:10 ` Christer Weinigel
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=477CFC89.1020409@panasas.com \
--to=bhalevy@panasas.com \
--cc=acme@redhat.com \
--cc=andyw@uk.ibm.com \
--cc=christer@weinigel.se \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox