llvm dev - Feb 2019 - RFC: changing variable naming rules in LLVM codebase

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:

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:

This comment seems to assume that camelBack is the agreed upon style and
all we need to do now is move forward, and I do not believe that to be the
case
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190219/059363ca/attachment.html>

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.

Best,

Alex

> It seems a bit early to discuss conversion given there’s not consensus on a
style.
My reason for pushing the conversion conversation is that if it's decided
that we want to clang-tidy everything then we have much more leeway in which
style we use. If we allow conversion to happen organically, then for that to
work we need to take into account the current style coexisting with the new
style, whatever that may be.

My fear is that if we insist on a big-bang transition then there will be
sufficient opposition that we end up making no change at all. For that reason I
favour allowing conversion to happen organically.
> This comment seems to assume that camelBack is the agreed upon style and
all we need to do now is move forward
No, I don't believe it's agreed upon, sorry to give that impression. I
see strong views on both sides. I just picked one for arguments sake.

On Tue, Feb 19, 2019 at 10:44 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

Not much to add, just a +1 : this is exactly my view as well.

-- 
Mehdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190219/23aa8deb/attachment.html>

Alex Bradbury <asb at lowrisc.org> wrote:
> 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
The specific concern I've seen raised is that when writing code you'll
need to check which form of variable name is used in a particular scope.

Clearly this is a cost, but given that code is read many times more than it is
written, I submit that this as a cost worth bearing for the sake of making it
easy to write good variable names.

If you see other costs then I'd be interested to know what those are.

There's a tool git-hyper-blame [1] that's designed to work well with
mass-refactoring commits.

It could aid a big-bang transition if we added a .git-blame-ignore-revs file. It
could also include IDs of previous NFC commits.

Does this make a big bang refactoring more palatable?

[1]
https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-hyper-blame.html

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

-Chris