llvm dev - Feb 2019 - changing variable naming rules in LLVM codebase

> On Feb 12, 2019, at 4:02 AM, Björn Pettersson A via llvm-dev <llvm-dev
at lists.llvm.org> wrote:
> 
> (Sorry if this subject already has been discussed, but I could not find any
clear rules/recommendations.)
>  
> What would the recommendation be for acronyms (I’ve seen the rule about
avoiding them unless they are “well known”,
> but sometimes an acronym is useful, and we at least need to have some
recommendation for the “well known” ones).
>  
> Example:
>  
>     if (ConstantExpr *CE = dyn_cast<ConstantExpr>(V))
>       if (CE->getOpcode() == Instruction::GetElementPtr &&
>           CE->getOperand(0)->isNullValue()) {
>  
> In the above example, is the recommendation to use “ce” instead of “CE”
now? Or should it be “cE”?
> With lowerCamelCase one might think that “cE” is the correct one (although
I personally think that one looks quite ugly).
In most examples, you’d use something other than an initialism.  I was the one
who started the whole CE thing as a contraction of the type into something
short, but there are almost always things that work otherwise.  For example, I’d
now write that example as:


    if (ConstantExpr *expr = dyn_cast<ConstantExpr>(value))
      if (expr->getOpcode() == Instruction::GetElementPtr &&
          expr->getOperand(0)->isNullValue()) {

or perhaps ‘constant' instead of ‘expr’.
 
> Maybe there should be an exception that variable names that start with an
acronym still should start with an upper case letter?
That would also be fine with me - it could push such a debate down the road, and
is definitely important for a transition period anyway.

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190213/82743b34/attachment-0001.html>

“CE” was just an example of a less common acronym. I think such an acronym
can be used for various purposes, so it is probably quite local in the code what
it
stands for.
We also have other (I think more common) acronyms like TLI for
TargetLoweringInfo, or MF for MachineFunction.

As Krzystzof were saying “Long names should be used where
meaning needs to be conveyed, otherwise they just obfuscate the code
needlessly.”
Having to write out targetLoweringInfo instead of the short form TLI
everywhere would probably obfuscate things (lots of long lines, line splits)
rather than making things easier to read/understand.


FWIW, there is a proposal in the RFC, and the coding standard still say that
acronyms may be used. I still haven’t seen any answers about what the
“correct way” would be when using an acronym if the RFC is accepted.
I’ve only seen answers about _not_ using acronyms, but that has not part
of the RFC afaict.

My point was that the RFC need to be clear about what to do with the
acronyms if we go down that path.

/Björn

From: Chris Lattner <clattner at nondot.org>
Sent: den 13 februari 2019 10:00
To: Björn Pettersson A <bjorn.a.pettersson at ericsson.com>
Cc: Michael Platings <Michael.Platings at arm.com>; llvm-dev at
lists.llvm.org
Subject: Re: [llvm-dev] changing variable naming rules in LLVM codebase




On Feb 12, 2019, at 4:02 AM, Björn Pettersson A via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:

(Sorry if this subject already has been discussed, but I could not find any
clear rules/recommendations.)

What would the recommendation be for acronyms (I’ve seen the rule about avoiding
them unless they are “well known”,
but sometimes an acronym is useful, and we at least need to have some
recommendation for the “well known” ones).

Example:

    if (ConstantExpr *CE = dyn_cast<ConstantExpr>(V))
      if (CE->getOpcode() == Instruction::GetElementPtr &&
          CE->getOperand(0)->isNullValue()) {

In the above example, is the recommendation to use “ce” instead of “CE” now? Or
should it be “cE”?
With lowerCamelCase one might think that “cE” is the correct one (although I
personally think that one looks quite ugly).

In most examples, you’d use something other than an initialism.  I was the one
who started the whole CE thing as a contraction of the type into something
short, but there are almost always things that work otherwise.  For example, I’d
now write that example as:


    if (ConstantExpr *expr = dyn_cast<ConstantExpr>(value))
      if (expr->getOpcode() == Instruction::GetElementPtr &&
          expr->getOperand(0)->isNullValue()) {
or perhaps ‘constant' instead of ‘expr’.

Maybe there should be an exception that variable names that start with an
acronym still should start with an upper case letter?

That would also be fine with me - it could push such a debate down the road, and
is definitely important for a transition period anyway.

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190213/46fe4fae/attachment.html>

On Wed, Feb 13, 2019 at 4:26 AM Björn Pettersson A via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> “CE” was just an example of a less common acronym. I think such an acronym
>
> can be used for various purposes, so it is probably quite local in the code
what it
>
> stands for.
>
> We also have other (I think more common) acronyms like TLI for
>
> TargetLoweringInfo, or MF for MachineFunction.
>
>
>
> As Krzystzof were saying “Long names should be used where
>
> meaning needs to be conveyed, otherwise they just obfuscate the code
>
> needlessly.”
>
> Having to write out targetLoweringInfo instead of the short form TLI
>
> everywhere would probably obfuscate things (lots of long lines, line
splits)
>
> rather than making things easier to read/understand.
>
>
>
>
>
> FWIW, there is a proposal in the RFC, and the coding standard still say
that
>
> acronyms may be used. I still haven’t seen any answers about what the
>
> “correct way” would be when using an acronym if the RFC is accepted.
>
> I’ve only seen answers about _not_ using acronyms, but that has not part
>
> of the RFC afaict.
>
>
>
> My point was that the RFC need to be clear about what to do with the
>
> acronyms if we go down that path.
I vote for treating acronyms like any other individual word written in
camel case or snake case.  That way, no one has to waste cycles trying
to dodge initial or consecutive acronyms when they make sense.

For example, given acronyms FOO and BAR, the phrase "FOO BAR" becomes
"fooBar", "FooBar", or "foo_bar".

Another occasional bonus is that a dictionary of acronyms isn't
required to automatically convert arbitrary names among the forms.

Some people think UpperCamelCase is ugly for acronyms, such as "Gdb"
or "Llvm".  That's the only objection I'm aware of for this
approach,
and it annoys me far less than the above issues.  Maybe I'm in the
minority.

Joel
>
>
>
> /Björn
>
>
>
> From: Chris Lattner <clattner at nondot.org>
> Sent: den 13 februari 2019 10:00
> To: Björn Pettersson A <bjorn.a.pettersson at ericsson.com>
> Cc: Michael Platings <Michael.Platings at arm.com>; llvm-dev at
lists.llvm.org
> Subject: Re: [llvm-dev] changing variable naming rules in LLVM codebase
>
>
>
>
>
>
>
> On Feb 12, 2019, at 4:02 AM, Björn Pettersson A via llvm-dev <llvm-dev
at lists.llvm.org> wrote:
>
>
>
> (Sorry if this subject already has been discussed, but I could not find any
clear rules/recommendations.)
>
>
>
> What would the recommendation be for acronyms (I’ve seen the rule about
avoiding them unless they are “well known”,
>
> but sometimes an acronym is useful, and we at least need to have some
recommendation for the “well known” ones).
>
>
>
> Example:
>
>
>
>     if (ConstantExpr *CE = dyn_cast<ConstantExpr>(V))
>
>       if (CE->getOpcode() == Instruction::GetElementPtr &&
>
>           CE->getOperand(0)->isNullValue()) {
>
>
>
> In the above example, is the recommendation to use “ce” instead of “CE”
now? Or should it be “cE”?
>
> With lowerCamelCase one might think that “cE” is the correct one (although
I personally think that one looks quite ugly).
>
>
>
> In most examples, you’d use something other than an initialism.  I was the
one who started the whole CE thing as a contraction of the type into something
short, but there are almost always things that work otherwise.  For example, I’d
now write that example as:
>
>
>
>
>
>     if (ConstantExpr *expr = dyn_cast<ConstantExpr>(value))
>       if (expr->getOpcode() == Instruction::GetElementPtr &&
>           expr->getOperand(0)->isNullValue()) {
>
> or perhaps ‘constant' instead of ‘expr’.
>
>
>
> Maybe there should be an exception that variable names that start with an
acronym still should start with an upper case letter?
>
>
>
> That would also be fine with me - it could push such a debate down the
road, and is definitely important for a transition period anyway.
>
>
>
> -Chris
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev