<div dir="ltr"><div dir="ltr">On Mon, Feb 18, 2019 at 9:22 AM Sanjoy Das via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Feb 18, 2019 at 2:16 AM Michael Platings via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> Regarding a plan for conversion, I'm keen to avoid perfect being the enemy of better.<br>
><br>
> 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.<br>
><br>
> So what's worse: inconsistent capitalization or keeping a convention that discourages good naming?<br>
><br>
> Taking my previous example [1]:<br>
><br>
> InnerLoopVectorizer LB(L, PSE, LI, DT, TLI, TTI, AC, ORE, VF.Width, IC,<br>
>   &LVL, &CM);<br>
><br>
> 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:<br>
><br>
> InnerLoopVectorizer LB(loop, PSE, loopInfo, DT, targetLibraryInfo, TTI,<br>
>   assumptionCache, ORE, vectorizationFactor.Width, IC,<br>
>   &loopVectorizationLegality, &CM);<br>
<br>
I find myself less productive in a codebase with inconsistent styling<br>
like you show above because it is more difficult to "guess" the name<br>
of a variable.  E.g. is the LoopInfo parameter named LI or loopInfo?<br>
I'll have to double check to be sure, which adds an extra step.<br>
<br>
So maybe a gradual transition plan could be to allow these upper case<br>
acronyms for specific classes?  For instance we could start by<br>
designating a set of "common" classes like Function, BasicBlock<br>
DominatorTree, LoopInfo, ScalarEvolution whose instances would<br>
instances still be called F, BB, DT, LI and SE, but mandate all other<br>
classes should use the new camelCase convention to name their<br>
instances?</blockquote><div><br></div><div>FWIW, I agree with the idea of this (the inconsistency is very expensive for me as well).</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>It would also largely match our *existing* points of divergence.</div><div> </div></div></div>