diff mbox series

[v1,2/3] Documentation/CodingStyle: do not use data type names as variable names

Message ID 20230304041932.847133-3-wei.w.wang@intel.com
State New
Headers
Series Regarding using 'bool' appropriately |

Commit Message

Wang, Wei W March 4, 2023, 4:19 a.m. UTC 
  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(+)

Comments

Jonathan Corbet March 4, 2023, 3:01 p.m. UTC | #1 
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
Wang, Wei W March 6, 2023, 11:03 a.m. UTC | #2 
On Saturday, March 4, 2023 11:02 PM, Jonathan Corbet wrote:
> 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.

OK. I thought people would not name it in this way. But it indeed happened,
and I don't find we have such rules officially documented anywhere.
Fine if you (or most people) think that's not necessary, though.
diff mbox series

Patch

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.
+
 5) Typedefs
 -----------