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

Chris Lattner via llvm-dev llvm-dev at lists.llvm.org
Wed Feb 20 08:57:38 PST 2019



> On Feb 19, 2019, at 3:27 AM, Michael Platings via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
>> FWIW, I suspect separating the transition of our acronyms from the transition
>> of identifiers with non-acronym words may be an effective way to chip away at
>> the transition cost... Definitely an area that people who really care about
>> this should look at carefully.
> 
> If it makes for an easier transition then I'd be happy to go with upper case acronyms and camelBack for non-acronyms. I've updated https://reviews.llvm.org/D57896 accordingly.

It isn’t clear to me that people are strongly in favor of upper case initialisms, it seems that people are opposed to changing TLI to “targetLibraryInfo”, which I can totally understand.

Communities that use these proposed conventions <https://swift.org/documentation/api-design-guidelines/#general-conventions> already include guidelines like this:
> Follow case conventions. Names of types and protocols are UpperCamelCase. Everything else is lowerCamelCase.
> 
> Acronyms and initialisms <https://en.wikipedia.org/wiki/Acronym> that commonly appear as all upper case in American English should be uniformly up- or down-cased according to case conventions:
> 
> var utf8Bytes: [UTF8.CodeUnit]
> var isRepresentableAsASCII = true
> var userSMTPServer: SecureSMTPServer
> Other acronyms should be treated as ordinary words:
> 
> var radarDetector: RadarScanner
> var enjoysScubaDiving = true

Among other nice things, this specifically means that things like “tli” are ok as is.



I think the significant point you raise is how to handle the transition.  I think that we can handle this in a soft way by saying something like “all new code should follow the conventions”, “old code shouldn’t be mass migrated”, “significant changes to old code can do local changes to improve adherence to convention”.  (or something like that).  This case is far from the only thing in LLVM that is inconsistent, so that seems like a reasonable global policy independent of the capitalization discussion.

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190220/7056abd5/attachment.html>


More information about the llvm-dev mailing list