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

TL;DR: change the rule for variable names from UpperCamelCase to lowerCamelCase.


Just to get wider visibility on this, I'm raising this again as an RFC, as
suggested by Roman Lebedev.


My original post from last week is here and gives a rationale:
http://lists.llvm.org/pipermail/llvm-dev/2019-February/129854.html. There seemed
to be general agreement that the status quo is not ideal.


Chris Lattner pointed out that this came up in 2014 as well:
http://lists.llvm.org/pipermail/llvm-dev/2014-October/077685.html


I've created a patch to implement the change. Review and comments welcome:
https://reviews.llvm.org/D57896
<http://lists.llvm.org/pipermail/llvm-dev/2014-October/077685.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190207/bd7df9f6/attachment.html>

An excellent first step toward improving our naming style, I'm all for it. 
Very much tired of circumlocutions like "Triple TheTriple;".
--paulr

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Michael
Platings via llvm-dev
Sent: Thursday, February 07, 2019 5:11 PM
To: llvm-dev at lists.llvm.org
Cc: nd
Subject: [llvm-dev] RFC: changing variable naming rules in LLVM codebase


TL;DR: change the rule for variable names from UpperCamelCase to lowerCamelCase.



Just to get wider visibility on this, I'm raising this again as an RFC, as
suggested by Roman Lebedev.



My original post from last week is here and gives a rationale:
http://lists.llvm.org/pipermail/llvm-dev/2019-February/129854.html. There seemed
to be general agreement that the status quo is not ideal.



Chris Lattner pointed out that this came up in 2014 as well:
http://lists.llvm.org/pipermail/llvm-dev/2014-October/077685.html



I've created a patch to implement the change. Review and comments welcome:
https://reviews.llvm.org/D57896
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190208/9b1f0301/attachment.html>

Just to add another data point: I’m pretty much in love with the lowerCamelCase.
To be more objective: I’ve such code across LLVM’s code base:

    class Dragon {};
    /// ...
    Dragon Dragon;

Which compiles correctly, but debuggers get confused when you ask them to do any
actions on Dragon: they could not differentiate between variable and class*.

* not sure if that’s still the case with the recent versions of gdb/lldb, but it
was caused some problems while debugging in the past.
> On 8. Feb 2019, at 16:41, via llvm-dev <llvm-dev at lists.llvm.org>
wrote:
> 
> An excellent first step toward improving our naming style, I'm all for
it.  Very much tired of circumlocutions like "Triple TheTriple;".
> --paulr
>  
> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
Michael Platings via llvm-dev
> Sent: Thursday, February 07, 2019 5:11 PM
> To: llvm-dev at lists.llvm.org
> Cc: nd
> Subject: [llvm-dev] RFC: changing variable naming rules in LLVM codebase
>  
> TL;DR: change the rule for variable names from UpperCamelCase to
lowerCamelCase.
>  
> Just to get wider visibility on this, I'm raising this again as an RFC,
as suggested by Roman Lebedev.
>  
> My original post from last week is here and gives a rationale:
http://lists.llvm.org/pipermail/llvm-dev/2019-February/129854.html. There seemed
to be general agreement that the status quo is not ideal.
>  
> Chris Lattner pointed out that this came up in 2014 as well:
http://lists.llvm.org/pipermail/llvm-dev/2014-October/077685.html
>  
> I've created a patch to implement the change. Review and comments
welcome: https://reviews.llvm.org/D57896
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

I don't care about the convention, but I'm really not sure it's
worth
the churn which would result in the code base.  The hurtle which needs 
cleared here is not "is it a better naming style", but "is the 
disruption implied by changing to the new convention justified".  To be 
clear, not opposed, just hesitant.


Philip


On 2/7/19 2:10 PM, Michael Platings via llvm-dev wrote:
>
> TL;DR: change the rule for variable names from UpperCamelCase to 
> lowerCamelCase.
>
>
> Just to get wider visibility on this, I'm raising this again as an 
> RFC, as suggested by Roman Lebedev.
>
>
> My original post from last week is here and gives a rationale: 
> http://lists.llvm.org/pipermail/llvm-dev/2019-February/129854.html. 
> There seemed to be general agreement that the status quo is not ideal.
>
>
> Chris Lattner pointed out that this came up in 2014 as well: 
> http://lists.llvm.org/pipermail/llvm-dev/2014-October/077685.html
>
>
> I've created a patch to implement the change. Review and comments 
> welcome: https://reviews.llvm.org/D57896
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190211/30d1b97e/attachment.html>

(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).

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

/Björn


From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Michael
Platings via llvm-dev
Sent: den 7 februari 2019 23:11
To: llvm-dev at lists.llvm.org
Cc: nd <nd at arm.com>
Subject: [llvm-dev] RFC: changing variable naming rules in LLVM codebase


TL;DR: change the rule for variable names from UpperCamelCase to lowerCamelCase.



Just to get wider visibility on this, I'm raising this again as an RFC, as
suggested by Roman Lebedev.



My original post from last week is here and gives a rationale:
http://lists.llvm.org/pipermail/llvm-dev/2019-February/129854.html. There seemed
to be general agreement that the status quo is not ideal.



Chris Lattner pointed out that this came up in 2014 as well:
http://lists.llvm.org/pipermail/llvm-dev/2014-October/077685.html



I've created a patch to implement the change. Review and comments welcome:
https://reviews.llvm.org/D57896
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190212/d56f5146/attachment.html>

I would assume that the proper name in this case is constantExpr, and not CE.
This is not really an acronym, but rather a shortcut taken for some unclear
reason.
> On 12. Feb 2019, at 13:02, 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).
>  
> Maybe there should be an exception that variable names that start with an
acronym still should start with an upper case letter?
>  
> /Björn
>  
>  
> From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of
Michael Platings via llvm-dev
> Sent: den 7 februari 2019 23:11
> To: llvm-dev at lists.llvm.org
> Cc: nd <nd at arm.com>
> Subject: [llvm-dev] RFC: changing variable naming rules in LLVM codebase
>  
> TL;DR: change the rule for variable names from UpperCamelCase to
lowerCamelCase.
> 
>  
> 
> Just to get wider visibility on this, I'm raising this again as an RFC,
as suggested by Roman Lebedev.
> 
>  
> 
> My original post from last week is here and gives a rationale:
http://lists.llvm.org/pipermail/llvm-dev/2019-February/129854.html. There seemed
to be general agreement that the status quo is not ideal.
> 
>  
> 
> Chris Lattner pointed out that this came up in 2014 as well:
http://lists.llvm.org/pipermail/llvm-dev/2014-October/077685.html
> 
>  
> 
> I've created a patch to implement the change. Review and comments
welcome: https://reviews.llvm.org/D57896
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

> 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>

On Thu, Feb 7, 2019 at 2:11 PM Michael Platings via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> TL;DR: change the rule for variable names from UpperCamelCase to
> lowerCamelCase.
>
>
> Just to get wider visibility on this, I'm raising this again as an RFC,
as
> suggested by Roman Lebedev.
>
>
> My original post from last week is here and gives a rationale:
> http://lists.llvm.org/pipermail/llvm-dev/2019-February/129854.html. There
> seemed to be general agreement that the status quo is not ideal.
>
>
> Chris Lattner pointed out that this came up in 2014 as well:
> http://lists.llvm.org/pipermail/llvm-dev/2014-October/077685.html
>
>
> I've created a patch to implement the change. Review and comments
welcome:
> https://reviews.llvm.org/D57896
>

I'm concerned about the internal inconsistency we would live with for
(likely) many years if there is not a migration plan to converge the code
base toward the new naming convention.
(other than that, changing the convention is fine with me, I don't have
much preference here)

-- 
Mehdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190214/909281b0/attachment.html>

On Thu, Feb 14, 2019 at 7:32 PM Mehdi AMINI via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
>
> On Thu, Feb 7, 2019 at 2:11 PM Michael Platings via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> TL;DR: change the rule for variable names from UpperCamelCase to
>> lowerCamelCase.
>>
>>
>> Just to get wider visibility on this, I'm raising this again as an
RFC,
>> as suggested by Roman Lebedev.
>>
>>
>> My original post from last week is here and gives a rationale:
>> http://lists.llvm.org/pipermail/llvm-dev/2019-February/129854.html.
>> There seemed to be general agreement that the status quo is not ideal.
>>
>>
>> Chris Lattner pointed out that this came up in 2014 as well:
>> http://lists.llvm.org/pipermail/llvm-dev/2014-October/077685.html
>>
>>
>> I've created a patch to implement the change. Review and comments
>> welcome: https://reviews.llvm.org/D57896
>>
>
>
> I'm concerned about the internal inconsistency we would live with for
> (likely) many years if there is not a migration plan to converge the code
> base toward the new naming convention.
> (other than that, changing the convention is fine with me, I don't have
> much preference here)
>
I think consistency within a function (for locals) and within a class (for
class members) is enough. I don't think that is any worse than the
consistency over
int *p;
versus
int* p;

>
> --
> Mehdi
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190214/0aaf4415/attachment.html>

On Mon, 11 Feb 2019 at 23:20, Philip Reames via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> I don't care about the convention, but I'm really not sure it's
worth the churn which would result in the code base.  The hurtle which needs
cleared here is not "is it a better naming style", but "is the
disruption implied by changing to the new convention justified".  To be
clear, not opposed, just hesitant.
I have the same concern. The whole advantage of a common coding
convention is consistency. There are exceptions, but the vast majority
of LLVM and Clang code I've read does indeed stick to the current
CamelCase convention. Unless there's a plan for conversion then the
practical impact of the naming convention change is that the codebase
will be a muddle of mixed conventions for years. That seems like a
regression, even if camelBack is a better convention.

On a more practical note, if the intent is to move to camelBack I
think it would be worth adding an example to the coding standard for
handling an acronym. e.g. is it the intent that TTI would become tti.

Best,

Alex