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

Björn Pettersson A via llvm-dev llvm-dev at lists.llvm.org
Tue Feb 12 04:02:28 PST 2019


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


More information about the llvm-dev mailing list