v2: Renamed from CamelCase to Snake case the variable nMcsRate, and
additionally removed the Hungarian notation of (n) that [v1] did not.
nMcsRate -> mcs_rate

Linux kernel coding style (cleanup), checkpatch Avoid CamelCase.
Driver/module rtl8192e compiles.

Signed-off-by: Gary Rookard <garyrookard@fastmail.org>
---
v2: Removes Hungarian notation.
v1: Renames from CamelCase only, Hungarian notation unremoved.

 drivers/staging/rtl8192e/rtl819x_HTProc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8192e/rtl819x_HTProc.c b/drivers/staging/rtl8192e/rtl819x_HTProc.c
index 00273d709f3c..4ed72936eb4a 100644
--- a/drivers/staging/rtl8192e/rtl819x_HTProc.c
+++ b/drivers/staging/rtl8192e/rtl819x_HTProc.c
@@ -103,7 +103,7 @@ void ht_update_default_setting(struct rtllib_device *ieee)
 	ht_info->rx_reorder_pending_time = 30;
 }
 
-static u16 ht_mcs_to_data_rate(struct rtllib_device *ieee, u8 nMcsRate)
+static u16 ht_mcs_to_data_rate(struct rtllib_device *ieee, u8 mcs_rate)
 {
 	struct rt_hi_throughput *ht_info = ieee->ht_info;
 
@@ -111,7 +111,7 @@ static u16 ht_mcs_to_data_rate(struct rtllib_device *ieee, u8 nMcsRate)
 	u8	isShortGI = (ht_info->bCurBW40MHz) ?
 			    ((ht_info->bCurShortGI40MHz) ? 1 : 0) :
 			    ((ht_info->bCurShortGI20MHz) ? 1 : 0);
-	return MCS_DATA_RATE[is40MHz][isShortGI][(nMcsRate & 0x7f)];
+	return MCS_DATA_RATE[is40MHz][isShortGI][(mcs_rate & 0x7f)];
 }
 
 u16  tx_count_to_data_rate(struct rtllib_device *ieee, u8 nDataRate)
-- 
2.41.0

On Tue, Nov 28, 2023 at 09:20:25AM -0500, Gary Rookard wrote:
> v2: Renamed from CamelCase to Snake case the variable nMcsRate, and
> additionally removed the Hungarian notation of (n) that [v1] did not.
> nMcsRate -> mcs_rate
> 
> Linux kernel coding style (cleanup), checkpatch Avoid CamelCase.
> Driver/module rtl8192e compiles.
> 
> Signed-off-by: Gary Rookard <garyrookard@fastmail.org>
> ---
> v2: Removes Hungarian notation.
> v1: Renames from CamelCase only, Hungarian notation unremoved.
> 
>  drivers/staging/rtl8192e/rtl819x_HTProc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/rtl8192e/rtl819x_HTProc.c b/drivers/staging/rtl8192e/rtl819x_HTProc.c
> index 00273d709f3c..4ed72936eb4a 100644
> --- a/drivers/staging/rtl8192e/rtl819x_HTProc.c
> +++ b/drivers/staging/rtl8192e/rtl819x_HTProc.c
> @@ -103,7 +103,7 @@ void ht_update_default_setting(struct rtllib_device *ieee)
>  	ht_info->rx_reorder_pending_time = 30;
>  }
>  
> -static u16 ht_mcs_to_data_rate(struct rtllib_device *ieee, u8 nMcsRate)
> +static u16 ht_mcs_to_data_rate(struct rtllib_device *ieee, u8 mcs_rate)

In the caller, this variable is called mcsRate, which presumably
checkpatch also complains about.  Why not rename them both to the same
thing?

It's unclear what value adding the "mcs_" prefix has, but I guess it's
nice to have a consistent variable name to grep for.

regards,
dan carpenter

On Tue, Nov 28, 2023 at 09:20:25AM -0500, Gary Rookard wrote:
> v2: Renamed from CamelCase to Snake case the variable nMcsRate, and
  ^^^^

> additionally removed the Hungarian notation of (n) that [v1] did not.
                                                           ^^^
Delete this stuff.  We are not going to merge v1 so we don't want to
mention it in the permanent git log.

> nMcsRate -> mcs_rate
> 
> Linux kernel coding style (cleanup), checkpatch Avoid CamelCase.
> Driver/module rtl8192e compiles.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is taken as a given.  Don't put this in the commit message.

> 
> Signed-off-by: Gary Rookard <garyrookard@fastmail.org>

This commit message is kind of bad.  A better commit message would be:

"Checkpatch complains about the "nMcsRate" variable because it is
CamelCase.  Rename it to "mcs_rate"".

There are a bunch of ways you could write the commit message but my
proposal is acceptable.  If you want to mention Hungarian notation you
can.  "Plus it's Hungarian notation and Hungarian notation is rubbish."
but that's not necessary.  If you're going to rename the variable then
we just consider that you're going to look at the context and the
surrounding code and pick a good consistent variable.

regards,
dan carpenter