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

[Krzysztof Parzyszek via llvm-dev]

The reason is clear: the variable name in such a context doesn't add 
anything, since it's obvious what it is. Long names should be used where 
meaning needs to be conveyed, otherwise they just obfuscate the code 
needlessly.

-Krzysztof

On 2/12/2019 3:17 PM, Alex Denisov via llvm-dev wrote:
> 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
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>