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

[Chandler Carruth via llvm-dev]

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>