[llvm-dev] RFC: changing variable naming rules in LLVM codebase (original) (raw)

Michael Platings via llvm-dev llvm-dev at lists.llvm.org
Mon Feb 18 02:15:58 PST 2019

Regarding a plan for conversion, I'm keen to avoid perfect being the enemy of better.

Privately, people I've spoken with have told me that they're opposed to a large scale conversion. Reasons given include breaking git blame, and creating needless merge conflicts. I might be wrong, but the evidence I've seen suggests that it's going to be very hard to get consensus on a conversion.

So what's worse: inconsistent capitalization or keeping a convention that discourages good naming?

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);

Yes it's inconsistent, but IMHO it still conveys so much more information than the original that the benefit greatly outweighs the cost.

So is the disruption implied by changing to the new convention justified? I think so.

[1] https://github.com/llvm/llvm-project/blob/ec0263027811f48b907224ede0dd24c33c1c7507/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp#L7433

More information about the llvm-dev mailing list