public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andy Whitcroft <apw@shadowen.org>
To: Krzysztof Halasa <khc@pm.waw.pl>
Cc: Alan Stern <stern@rowland.harvard.edu>,
	Randy Dunlap <rdunlap@xenotime.net>,
	Joel Schopp <jschopp@austin.ibm.com>,
	Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: Possible false positive in checkpatch
Date: Tue, 12 Aug 2008 18:18:00 +0100	[thread overview]
Message-ID: <20080812171800.GA29207@brain> (raw)
In-Reply-To: <m3d4kefe0x.fsf@maximus.localdomain>

On Tue, Aug 12, 2008 at 05:29:02PM +0200, Krzysztof Halasa wrote:
> Alan Stern <stern@rowland.harvard.edu> writes:
> 
> > ERROR: space prohibited after that '*' (ctx:BxW)
> 
> 
> > Certainly this is a rather uncommon code construction, but similar
> > ones might occur elsewhere.  To my eyes,
> >
> > 	(* (type *) ptr)
> >
> > looks better than
> >
> > 	(*(type *) ptr)
> >
> > or
> >
> > 	(*(type *)ptr)
> >
> > or even
> >
> > 	(*(type*)ptr)
> >
> > but of course this is a matter of opinion.  Is there any strong feeling 
> > about this in the kernel community?
> 
> I think checkpatch already has gone way too far with this (and not
> only this).
> 
> "type *var" vs "type* var" - sure, the latter is worse and provokes
> "type* var1, var2", but anything else is IMHO only annoying and,
> actually, not important WRT readability at all.
> 
> For example I prefer "type* func()" - as it's a function returning
> "a pointer to type" and not "a pointer to a function returning type"
> (which "type *func()" may suggest). Yes, func is not a pointer, so why
> write "*" next to it?

The recommendations it makes match the style of the whole, which new
contributions should follow.  To a lot of people these nuances don't
matter to others they do.  checkpatch aims to tell you what you will
likely be picked up on.  Its recommending a standardised style that is
not necessarily what any one of us would use.  But that is its role.
Feel free to ignore any of its recommendations, but expect to be pulled
up on a lot of them if you do; remembering the time of the reviewer
that is wasted in doing so.

-apw

  reply	other threads:[~2008-08-12 17:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-12 14:25 Possible false positive in checkpatch Alan Stern
2008-08-12 15:29 ` Krzysztof Halasa
2008-08-12 17:18   ` Andy Whitcroft [this message]
2008-08-12 18:01     ` Krzysztof Halasa
2008-08-15 21:58 ` H. Peter Anvin
2008-08-16 15:26   ` Alan Stern

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=20080812171800.GA29207@brain \
    --to=apw@shadowen.org \
    --cc=jschopp@austin.ibm.com \
    --cc=khc@pm.waw.pl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rdunlap@xenotime.net \
    --cc=stern@rowland.harvard.edu \
    /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