linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Joe Perches <joe@perches.com>,
	Markus Heiser <markus.heiser@darmarit.de>,
	Matthew Wilcox <willy@infradead.org>
Cc: Mike Rapoport <rppt@linux.ibm.com>, linux-doc@vger.kernel.org
Subject: Re: Return: vs Returns:
Date: Fri, 08 Feb 2019 09:31:31 +0200	[thread overview]
Message-ID: <87d0o27n3g.fsf@intel.com> (raw)
In-Reply-To: <b6261331cb0c766ed213ab8986df1b30c4f7b719.camel@perches.com>

On Thu, 07 Feb 2019, Joe Perches <joe@perches.com> wrote:
> On Thu, 2019-02-07 at 18:58 +0100, Markus Heiser wrote:
>> Am 07.02.19 um 18:50 schrieb Joe Perches:
>> > On Thu, 2019-02-07 at 09:34 -0800, Matthew Wilcox wrote:
>> > > On Thu, Feb 07, 2019 at 09:31:20AM -0800, Joe Perches wrote:
>> > > > It's not clear to me what you are asking checkpatch to do here.
>> > > > 
>> > > > It may be reasonable for checkpatch to invoke kernel-doc on some
>> > > > portion of a patch, but I'm not sure how valuable it will be.
>> > > 
>> > > I was just hoping to match:
>> > > 
>> > >   * Returns:
>> > > 
>> > > Or to quote it properly for regexes ...
>> > > 
>> > > ^ +\* *Returns:
>> > > 
>> > > (I think ...)
>> > > 
>> > > I can't see that matching C or assembler.
>> > 
>> > checkpatch doesn't attempt to enforce any formatting standard
>> > on kernel-doc comments.
>> > 
>> > There doesn't seem to be much standardization for kernel-doc
>> > in the first place.
>> > 
>> > Just for the * return: case:
>> > 
>> > $ git grep -P -i '^\s*\*\s*returns?\s*:' -- '*.[ch]' | \
>> >    grep -P -oh -i '\*\s*returns?\s*:' | \
>> >    sort | uniq -c | sort -rn
>> >     5153 * Return:
>> >     2534 * Returns:
>> >     1077 * RETURN:
>> >      358 * RETURNS:
>> >      173 *	RETURNS:
>> >      171 * returns:
>> >      153 * return:
>> >      148 * Return :
>> >       72 * Returns :
>> >       61 *	Returns:
>> >       37 *  Returns:
>> >       30 *  returns:
>> >       27 *  return:
>> >       22 *	Return:
>> >       20 * Returns  :
>> >       19 *  Return:
>> >       15 *  RETURNS:
>> >       11 *           return:
>> >        6 * return :
>> >        6 *	return:
>> >        5 * returns :
>> >        3 *Returns:
>> >        3 * Returns	:
>> >        3 * 	returns:
>> >        2 *RETURNS:
>> >        2 *     Returns:
>> >        2 *      Returns:
>> >        2 *	returns:
>> >        2 * RETURN :
>> >        2 *      Return:
>> >        2 * 	Return:
>> >        2 *	return :
>> >        2 *		return:
>> >        1 *   RETURNS:
>> >        1 * RETURNs:
>> >        1 *   Returns:
>> >        1 *    Returns:
>> >        1 * 	Returns:
>> >        1 *  RETURN:
>> >        1 *   Return:
>> >        1 *    Return:
>> >        1 * return   :
>> > 
>> > I think standarization is more something that scripts/kernel-doc
>> > could or should do.
>> 
>> BTW: kernel-doc parser accept 'return' and 'returns':
>> 
>>      } elsif ($newsection =~ m/^return?$/i) {
>>          $newsection = $section_return;
>
> That regex doesn't look like it does accept returns.

Yeah that copy-paste is from who knows where, kernel-doc DTRT.

> That looks like it accepts either retur or return.
> I believe that would need to be
>
> 	$newsection =~ m/returns?$/i
>
>> Is there really a need to be standardize this?
>
> I generally doubt it.

I ran a regex similar to yours (there's also "@returns?:") way back when
adding Sphinx support, and my conclusion was trying to standardize this
is futile. Sure we can document and encourage one (I chose "Return:"
based on the grep popularity contest) but trying to change everything is
just unnecessary busywork.

However, kernel-doc does standardize the *output* for more uniform and
nicer looking results.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

  reply	other threads:[~2019-02-08  7:30 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-07 13:59 Return: vs Returns: Matthew Wilcox
2019-02-07 15:30 ` Mike Rapoport
2019-02-07 15:58   ` Markus Heiser
2019-02-07 16:18     ` Mike Rapoport
2019-02-07 17:31       ` Joe Perches
2019-02-07 17:34         ` Matthew Wilcox
2019-02-07 17:50           ` Joe Perches
2019-02-07 17:58             ` Markus Heiser
2019-02-07 18:03               ` Joe Perches
2019-02-08  7:31                 ` Jani Nikula [this message]
2019-02-07 18:03               ` Markus Heiser
2019-02-07 17:33       ` Markus Heiser
2019-02-08 10:55         ` Mike Rapoport

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=87d0o27n3g.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=joe@perches.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=markus.heiser@darmarit.de \
    --cc=rppt@linux.ibm.com \
    --cc=willy@infradead.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;
as well as URLs for NNTP newsgroup(s).