linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Tanjuate Brunostar <tanjubrunostar0@gmail.com>
Cc: linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org,
	outreachy@lists.linux.dev
Subject: Re: [PATCH 05/17] staging: vt6655: changed variable name: pvRTS
Date: Wed, 26 Oct 2022 15:51:44 +0200	[thread overview]
Message-ID: <Y1k7cDP4Dpdr5EOe@kroah.com> (raw)
In-Reply-To: <47da976cd02d262cebe520b21a0bf2451de6731b.1666740522.git.tanjubrunostar0@gmail.com>

On Tue, Oct 25, 2022 at 11:37:01PM +0000, Tanjuate Brunostar wrote:

Philipp has pointed out most of this already, but I'll just be specific
and say what isn't ok in all of these patches:

> 	change variable names pvRTS to meet the

"name" not "name"

>         linux coding standard, as it says to avoid using camelCase naming

"Linux" not "linux"

>         style. Cought by checkpatch

Why is this all indented?

Please do not do that, look at existing accepted changes in the git log
and match up what they look like.

But worst of all, you didn't really fix the variable name at all.  You
just appeased a tool that was trying to say "don't use camelCase, use
sane names".

> Signed-off-by: Tanjuate Brunostar <tanjubrunostar0@gmail.com>
> ---
>  drivers/staging/vt6655/rxtx.c | 56 +++++++++++++++++------------------
>  1 file changed, 28 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/staging/vt6655/rxtx.c b/drivers/staging/vt6655/rxtx.c
> index 2cac8f3882df..e97cba014adf 100644
> --- a/drivers/staging/vt6655/rxtx.c
> +++ b/drivers/staging/vt6655/rxtx.c
> @@ -87,7 +87,7 @@ static const unsigned short w_fb_opt_1[2][5] = {
>  /*---------------------  Static Functions  --------------------------*/
>  static void s_v_fill_rts_head(struct vnt_private *p_device,
>  			      unsigned char by_pkt_type,
> -			      void *pvRTS,
> +			      void *pv_rts,

"pvRTS" is using Hungarian Notation.  Look it up on Wikipedia for what
it means, and why people used to use it.

For us, we don't need that at all as the type of the variable is obvious
in the code and the compiler checks it.

So "pvRTS" is trying to say "this is a pointer to void called "RTS".

We don't care about the "describe the variable type in the name" thing,
so it should just be called "RTS", or better yet, "rts", right?

But then, step back.  Why is this a void pointer at all?  This is really
a structure of type struct vnt_rts_g_fb.  So why isn't that being passed
here instead?

So try to work on both, fixing up the names to be sane, and then,
getting rid of the void * stuff, to better reflect how data is flowing
around and what type that data is in.

thanks,

greg k-h

  reply	other threads:[~2022-10-26 13:51 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-25 23:36 [PATCH 00/17] staging: vt6655: a series of checkpatch fixes on the file: rxtx.c Tanjuate Brunostar
2022-10-25 23:36 ` [PATCH 01/17] staging: vt6655: changed variable names: wFB_Opt0 Tanjuate Brunostar
2022-10-26  2:46   ` Philipp Hortmann
2022-10-26  3:24   ` Philipp Hortmann
2022-10-25 23:36 ` [PATCH 02/17] staging: vt6655: changed variable names: s_vFillRTSHead Tanjuate Brunostar
2022-10-26  2:56   ` Philipp Hortmann
2022-10-26 13:52   ` Greg KH
2022-10-25 23:36 ` [PATCH 03/17] staging: vt6655: changed variable name: pDevice Tanjuate Brunostar
2022-10-26  3:03   ` Philipp Hortmann
2022-10-25 23:37 ` [PATCH 04/17] staging: vt6655: changed variable name: byPktType Tanjuate Brunostar
2022-10-25 23:37 ` [PATCH 05/17] staging: vt6655: changed variable name: pvRTS Tanjuate Brunostar
2022-10-26 13:51   ` Greg KH [this message]
2022-10-27  6:12     ` Tanju Brunostar
2022-10-25 23:37 ` [PATCH 06/17] staging: vt6655: changed variable name: cbFrameLength Tanjuate Brunostar
2022-10-25 23:37 ` [PATCH 07/17] staging: vt6655: changed variable name: b_need_ack Tanjuate Brunostar
2022-10-25 23:37 ` [PATCH 08/17] staging: vt6655: changed variable name: bDisCRC Tanjuate Brunostar
2022-10-25 23:37 ` [PATCH 09/17] staging: vt6655: changed variable name: byFBOption Tanjuate Brunostar
2022-10-25 23:37 ` [PATCH 10/17] staging: vt6655: changed variable name: s_vGenerateTxParameter Tanjuate Brunostar
2022-10-25 23:37 ` [PATCH 11/17] staging: vt6655: changed variable name: pvRrvTime Tanjuate Brunostar
2022-10-25 23:37 ` [PATCH 12/17] staging: vt6655: changed variable name: cbFrameSize Tanjuate Brunostar
2022-10-25 23:37 ` [PATCH 13/17] staging: vt6655: changed variable name: bNeedACK Tanjuate Brunostar
2022-10-25 23:37 ` [PATCH 14/17] staging: vt6655: changed variable name: uDMAIdx Tanjuate Brunostar
2022-10-25 23:37 ` [PATCH 15/17] staging: vt6655: changed variable name: psEthHeader Tanjuate Brunostar
2022-10-25 23:37 ` [PATCH 16/17] staging: vt6655: changed variable name: s_cbFillTxBufHead Tanjuate Brunostar
2022-10-25 23:37 ` [PATCH 17/17] staging: vt6655: changed variable name: pbyTxBufferAddr Tanjuate Brunostar

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=Y1k7cDP4Dpdr5EOe@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=outreachy@lists.linux.dev \
    --cc=tanjubrunostar0@gmail.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;
as well as URLs for NNTP newsgroup(s).