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

[David Blaikie via llvm-dev]

On Fri, Aug 20, 2021 at 12:03 AM Andy Wingo <wingo at igalia.com> wrote:

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

Any idea what, if anything, they did to address issues of revision history
navigation, helping people update their outstanding patches over the
transition, etc?


>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210820/0f78c796/attachment.html>