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

[Alex Bradbury via llvm-dev]

On Wed, 20 Feb 2019 at 17:07, Chris Lattner <clattner at nondot.org> wrote:
> > On Feb 19, 2019, at 7:43 AM, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> >
> > On Tue, 19 Feb 2019 at 15:24, Zachary Turner <zturner at google.com> 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.
> >>
> >>
> >> It seems a bit early to discuss conversion given there’s not consensus on a style.  For example:
> >
> > I see it a bit differently. The first question is "should we change
> > the LLVM naming conventions". I view the plan for conversion as
> > essential to answering this question - IMHO if we're going to live
> > with mixed styles for years (which would be the case if there were no
> > concerted conversion effort) then the advantages of changing naming
> > convention are outweighed by the disadvantages by quite some way. So
> > while I appreciate the desire to separate concerns, I find it
> > difficult to do so in this case.
>
> I absolutely respect that position and concern, but there are other factors to consider.  Let’s assume that we all agreed that a change was the right thing to do, and we were only concerned about the transition (just to simplify the discussion):
>
> 1) Transition cost can be used to argue against *any* global improvement to an existing codebase.  The GCC community used this argument for many years arguing against moving to C++ from C.  It is true that there will be a time of transition, but at some point in time, you just decide that the cost of a global mechanical change is worth it and you get to consistency.
>
> 2) Tremendous amounts of new code is being written, and lots of existing code is being touched.  This provides opportunities to incrementally migrate.
>
> 3) The cost of inconsistency is low, because the affected declarations typically have local scope.  Even the affected globals in LLVM are typically static within a file.  This means that you don’t need a global index to go what is going on.  Variables and functions are also often named quite different (e.g. functions often use imperative verbs).
>
> 4) The LLVM community and project is growing through new subprojects, new targets, and other new things, and holding back the “correct” thing in new subprojects because of legacy code in other parts of the project doesn’t make sense.
>
>
> That said, I understand that there is still controversy about whether making a change would improve the project, I just wanted to point out that if we converge on that, then we should consider what LLVM looks like 10 years from now, not just what it looks like 6 months from now.  I for one don’t want to see LLVM stagnate, slow, and suffer because of legacy concerns.

Thanks for elaborating on your thinking Chris. The point about new
subprojects etc is a particularly strong one.

It wasn't clear from my previous email, but my general inclination is
to pursue global improvements such as this, and to combine them with a
somewhat aggressive transition plan in order for the benefits to be
reaped sooner (and to minimise the cost of inconsistency).

Best,

Alex