kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: pablo9891@gmail.com (Pablo Pellecchia)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Really long lenght macros names on wlan-ng directory
Date: Mon, 24 Sep 2018 01:58:25 -0300	[thread overview]
Message-ID: <CADN=kBmYvEaRE+bHiL8bi2FgEXFUoFNqjbGec2=pK2G85ui8DQ@mail.gmail.com> (raw)

Hi all,

Lately I've been doing manteinance of code on the drivers/staging/wlan-ng
directory and found that there is a (seems like an auto generated code)
p80211metadef.h file that is using long lenght macro names breking not only
camel case convention, producing checkpatch issues when tested, but also
generating a lot of "over 80 characters" warnings all over the code. Take
the following as an example:

DIDmib_dot11smt_dot11PrivacyTable_dot11PrivacyInvoked

So I decided to do some refactor and try to make a shorter version of those
macros and also avoid camel case. I came up with something like this:

DIDMIB_DOT11SMT_DOT11PRCYTBL_DOTPRCYINVKD

Not as short as expected, but at least we avoid camel case convention, we
use an entire caps convention for macro and we keep information and context
about what the macro does.Most of the "over 80 characters" issues all over
the code seem to be gone, based on a quick compare between the old
checkpatch test and latest one but still I have a question... Take this
code as an example:

result = prism2_domibset_uint32(wlandev,

DIDMIB_DOT11SMT_DOT11PRCYTBL_DOT11WEBDEFKYID,
                                                sme->key_idx);

Is this something I really want to fix given that the disadvantage is that
by reducing the lenght I take context from what the variable does? Cases
like this replicates all over the code. My idea would be to make an
standard convention, something like DOT11_DIDMIB_PRCYTBL_WEBDEFKYID. So if
we have the DOT11 at the beginning we know that it's a variable related to
the 80211.11 standard therefore everything that comes after has to be
understood in that context. That would save a lot of space but I am not
sure of the reasons for which someone would need a long name as these.
Maybe someone else has good reasons to keep this type of naming. My guest
is that because this is an autogenerated code no one cared about naming
conventions.

I'm a little confused here with this so I would appreciate some advices on
this.

Thanks!
-- Pablo --
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180924/7330da99/attachment.html>

                 reply	other threads:[~2018-09-24  4:58 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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='CADN=kBmYvEaRE+bHiL8bi2FgEXFUoFNqjbGec2=pK2G85ui8DQ@mail.gmail.com' \
    --to=pablo9891@gmail.com \
    --cc=kernelnewbies@lists.kernelnewbies.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).