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

[Krzysztof Parzyszek via llvm-dev]

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.

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