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

[Chris Lattner via llvm-dev]

> On Feb 18, 2019, at 12:09 PM, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> On 2/18/2019 4:15 AM, Michael Platings via llvm-dev wrote:
>> Taking my previous example [1]:
>> InnerLoopVectorizer LB(L, PSE, LI, DT, TLI, TTI, AC, ORE, VF.Width, IC,
>>   &LVL, &CM);
>> If we imagine that over time it evolves such that 50% of the variables have been renamed to camelBack versions of the type names, then it will look like this:
>> InnerLoopVectorizer LB(loop, PSE, loopInfo, DT, targetLibraryInfo, TTI,
>>   assumptionCache, ORE, vectorizationFactor.Width, IC,
>>   &loopVectorizationLegality, &CM);
> 
> Hold on...
> 
> The change from UpperCamel to lowerCamel should be separate from going from X to somethingOtherName.
> 
> It seems like in this example, TLI is changed to targetLibraryInfo for the purpose of having a name that lowerCamel can be applied to, which is, at best, backwards.

I completely agree.  I don’t see why “tli” would be problematic.  I don’t think that “targetLibraryInfo” would make the code easier to read, write, or maintain.

-Chris



> 
> When a new person sees "TLI", they won't know what it is. When an LLVM developer sees "TLI" they know exactly what it is, even without any context. At the same time, a person is new to LLVM for only a certain period of time, much shorter than the lifetime of the code.
> 
> The key to readability is to make the important things easy to see, and get the unimportant things out of the way. By using completely expanded names we run the risk of making everything equally "easy to see"...
> 
> -Krzysztof
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev