[llvm-dev] RFC: changing variable naming rules in LLVM codebase
Krzysztof Parzyszek via llvm-dev
llvm-dev at lists.llvm.org
Mon Feb 18 12:09:52 PST 2019
On 2/18/2019 4:15 AM, Michael Platings via llvm-dev wrote:
> Taking my previous example :
> 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);
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"...
More information about the llvm-dev