[llvm-dev] changing variable naming rules in LLVM codebase

[Joel E. Denny via llvm-dev]

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