[llvm-dev] Top-level .clang-tidy options and VariableName suggestion on CodingStandards

[Andy Wingo via llvm-dev]

Hi,

Just a couple cents from a relative newcomer to LLVM, please take them
with their appropriate worth ;)

On Thu 19 Aug 2021 21:21, David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> writes:

> 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.

FWIW I found when switching between lld and llvm to be jarring -- I had
to know that there were two coding conventions, and that one was
documented and one was not.  It wasted a bit of reviewer time pointing
out these issues (though of course the tools helped).

> I don't think that future direction must include a way to cleanup LLVM
> - as Chris Lattner said, maybe it is something like "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. 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). - Dave

Here again I found problems when switching to clang -- you end up with
different naming conventions per file (what is the convention for
https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/ConstantEmitter.h
?  When making a patch, which convention to use?) and sometimes even
within a file (consider
https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/CodeGenFunction.h#L4819-L4831
vs
https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/CodeGenFunction.h#L1484-L1491).
So when making a patch I have to know not only the coding convention but
also the direction that things are supposed to be going, and there does
not appear to be project-wide consensus on that.

Also just FWIW, when I was working on Firefox they changed coding
conventions but did so with a big bang switch.  I found it much easier
to navigate -- the situation was at all times clear to me.

>From my limited perspective It Would Be Good™ if llvm would end up in a
situation where the coding conventions were always enforced -- the
situation in clang is perhaps the least desirable one.  And bonus if it
is the same convention across the project :)

Regards,

Andy