All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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 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.