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

Chandler Carruth via llvm-dev llvm-dev at lists.llvm.org
Mon Feb 18 17:33:47 PST 2019

On Mon, Feb 18, 2019 at 9:22 AM Sanjoy Das via llvm-dev < llvm-dev at lists.llvm.org> wrote:

On Mon, Feb 18, 2019 at 2:16 AM Michael Platings via llvm-dev <llvm-dev at lists.llvm.org> wrote: > 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);

I find myself less productive in a codebase with inconsistent styling like you show above because it is more difficult to "guess" the name of a variable. E.g. is the LoopInfo parameter named LI or loopInfo? I'll have to double check to be sure, which adds an extra step. So maybe a gradual transition plan could be to allow these upper case acronyms for specific classes? For instance we could start by designating a set of "common" classes like Function, BasicBlock DominatorTree, LoopInfo, ScalarEvolution whose instances would instances still be called F, BB, DT, LI and SE, but mandate all other classes should use the new camelCase convention to name their instances?

FWIW, I agree with the idea of this (the inconsistency is very expensive for me as well).

However, I would find tying it to the type still terribly difficult. I would have a very hard time remembering which classes were part of which set.

Personally, I'd much rather the granularity of either an "interface" (type + methods, or overload set of namespace functions) being consistent, or a "file" being consistent. Both of those would be much cheaper for me to remember and reliably follow.

It would also largely match our existing points of divergence. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190218/83d2009e/attachment.html>

More information about the llvm-dev mailing list