Really long lenght macros names on wlan-ng directory

[Pablo Pellecchia]

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>