<div dir="ltr"><div dir="ltr">On Fri, Aug 20, 2021 at 3:58 PM Nicolai Hähnle <<a href="mailto:nhaehnle@gmail.com">nhaehnle@gmail.com</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"><div dir="ltr"><div class="gmail_quote"><div class="gmail_attr">First of all, thank you for pushing on this topic. I would agree that UpperCamelCase naming style was a mistake.<br></div><div dir="ltr" class="gmail_attr"><br></div>[snip] <br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"></div><div class="gmail_quote">> Further thought: I don't think (1) should proceed as-is no matter the decision on (2). We should have an LLVM umbrella naming convention (I don't think the number of projects that use one or the other should be a vote in favor or against - LLVM Core is still the core of the umbrella project and has more weight here than other subprojects (not the only thing that matters, but part of it), removing any naming convention I think would be unhelpful.<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> & I don't think (2) should be "use either of these naming conventions" it should be "this is the naming convention" perhaps with a note that LLVM Core (& some other places, such as clang-tools-extra) uses a different one for historical reasons, for instance.<br></blockquote></div></div></blockquote><div><br></div><div>That sounds fair.</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><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">
There were debates about whether camelCase/snake_case should be used<br>
for variable names,<br>
Personally I am fine with either one but slightly prefer snake_case.<br>
New projects using either form will be fine to me.<br>
<br>
For (1), I have some doubt whether there will be an LLVM umbrella<br>
naming convention for variable names,<br>
but I **don't** consider the lack of convergence (to either camelCase<br>
or snake_case) an argument for keeping VariableName in the in the<br>
top-level .clang-tidy .<br>
Actually I strongly oppose to keeping VariableName in the top-level<br>
.clang-tidy, or new projects adopting VariableName.<br></blockquote><div><br></div><div>It's pretty important to me that we don't make it easier to create more divergence in naming conventions - creating another project that diverges from LLVM's naming conventions/creates more naming inconsistency seems like a loss to me. So until there's some buy-in for a desired future direction, I think new projects should adhere to the existing convention.<br><br>I don't think that future direction must include a way to cleanup LLVM - as Chris Lattner said, maybe it is something like "<span style="color:rgb(0,0,0);white-space:pre-wrap">Even if the community does not have the appetite to do a huge scale renaming of all the things in LLVM, it would be interesting to carve out an exception for new code being written, refactored, or potentially for use in new subprojects." - though I think that's a choice we should all make together (doesn't require it to be unanimous) and carefully. That does produce the inconsistent-with-LLVM-core issue I'm concerned about, but maybe with a path forward to consistency.</span></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><span style="color:rgb(0,0,0);white-space:pre-wrap">
Might be worth talking about whether people would be comfortable with more active cleanup - not necessarily one huge renaming, but be willing to accept patches that rename things without necessarily being pieces of code being actively refactored for other reasons. That'd help alleviate the "now we're going to have N different conventions based on when a given subproject was introduced", which increases friction when moving between subprojects (as zturner pointed out in some of the discussion/code review of style changes proposed previously).</span></div></div></div></blockquote><div><br></div><div>My view is that changes for purely stylistic reasons hurt *much* more than switching between projects with different variable naming styles.</div><div><br></div><div>LLVM de facto very much has a distributed development model. Even teams that work close to upstream often have their own branches where changes are developed before they are ready for Phabricator. Style changes have a tendency to introduce totally pointless merge failures.</div></div></div></blockquote><div><br></div><div>I don't think they're totally pointless or busywork (there's value in the consistency, but there's significant costs to get there) - but they are real costs to consider, to be sure.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> Anybody who is proposing purely stylistic changes is *usually* proposing creating a lot of busywork for a lot of people. It*s just not worth it.</div></div></div></blockquote><div><br>Part of my hope would be that if we do wider scale cleanups we'll do so with tooling to make it easier for out of tree branches and patches to update to match the in-tree changes. (& one significant period of pain, rather than refactoring a file at a time from time to time)<br><br>Also having different naming per file (or worse) is sort of where clang is, and has been an ongoing source of difficulty - so I think it'd be good to avoid that. I'd be amenable to a per-directory naming convention migration - using .clang-tidy files to document the format for a given directory/make it easy for developers to know what convention to use in a given location. But I suspect it'd be better overall to adopt a more "all or nothing" approach (keep one convention per subproject at least - accepting that that means LLVM Core would never change - which I think would be unfortunate).<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>(Sometimes, stylistic cleanups are truly confined to a single file. In that case, they may be fine, especially when the file doesn't change very much in the first place. As soon as you're changing names in header files, though, you're very likely going to cause problems.)</div><div><br></div><div>*Mandating* a move away from UpperCamelCase for *new* code, and *allowing* (or perhaps *suggesting*) renames away from UpperCamelCase for code that is being refactored anyway, is the way to go in my opinion.<br></div><div><br></div><div>Cheers,</div><div>Nicolai<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><span style="color:rgb(0,0,0);white-space:pre-wrap">

- Dave</span></div></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr">Lerne, wie die Welt wirklich ist,<br>aber vergiss niemals, wie sie sein sollte.</div></div>
</blockquote></div></div>