public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Corbet <corbet@lwn.net>
To: Wei Wang <wei.w.wang@intel.com>,
	arnd@arndb.de, akpm@linux-foundation.org, keescook@chromium.org,
	herbert@gondor.apana.org.au, josh@joshtriplett.org,
	jani.nikula@intel.com, jgg@mellanox.com, dmatlack@google.com,
	mizhang@google.com, pbonzini@redhat.com, seanjc@google.com
Cc: linux-kernel@vger.kernel.org, Wei Wang <wei.w.wang@intel.com>
Subject: Re: [PATCH v1 2/3] Documentation/CodingStyle: do not use data type names as variable names
Date: Sat, 04 Mar 2023 08:01:46 -0700	[thread overview]
Message-ID: <87mt4szhk5.fsf@meer.lwn.net> (raw)
In-Reply-To: <20230304041932.847133-3-wei.w.wang@intel.com>

Wei Wang <wei.w.wang@intel.com> writes:

> Observed some merged code uses "bool" as variable name. This is
> confusion either for the reader or compilier. Add a rule to have
> programmers avoid using data types as variable names.
>
> Signed-off-by: Wei Wang <wei.w.wang@intel.com>
> ---
>  Documentation/process/coding-style.rst | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst
> index 007e49ef6cec..6d7f4069d55d 100644
> --- a/Documentation/process/coding-style.rst
> +++ b/Documentation/process/coding-style.rst
> @@ -356,6 +356,9 @@ specification that mandates those terms. For new specifications
>  translate specification usage of the terminology to the kernel coding
>  standard where possible.
>  
> +"bool", "int", "long" etc. are specific names for data types, C
> +programmers should not use them as variable names.

It seems you found one place where bool was being misused.  Fixing it
was certainly the right thing to do, but I'm not convinced we need to
add clutter to the documentation for this.

Thanks,

jon

  reply	other threads:[~2023-03-04 15:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-04  4:19 [PATCH v1 0/3] Regarding using 'bool' appropriately Wei Wang
2023-03-04  4:19 ` [PATCH v1 1/3] security: keys: don't use data type as variable name Wei Wang
2023-03-11 22:13   ` Jarkko Sakkinen
2023-03-04  4:19 ` [PATCH v1 2/3] Documentation/CodingStyle: do not use data type names as variable names Wei Wang
2023-03-04 15:01   ` Jonathan Corbet [this message]
2023-03-06 11:03     ` Wang, Wei W
2023-03-04  4:19 ` [PATCH v1 3/3] bug: use bool for __ret_warn_on in WARN/WARN_ON Wei Wang

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=87mt4szhk5.fsf@meer.lwn.net \
    --to=corbet@lwn.net \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=dmatlack@google.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=jani.nikula@intel.com \
    --cc=jgg@mellanox.com \
    --cc=josh@joshtriplett.org \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mizhang@google.com \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=wei.w.wang@intel.com \
    /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