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

[David Greene via llvm-dev]

Here's what I could find on the thread:

http://lists.llvm.org/pipermail/llvm-dev/2019-February/130430.html

"This is not how I described my preference for it. I prefer it generally and
find it substantially easier to read code using it.

That said, I think the fact that LLDB uses it does contribute two
motivations:
1) It does show some subset of the community is familiar with it and has
found it to be a reasonably good convention for their usage.
2) It removes some cost of transition.

I wouldn't make the decision *because* of this, but I also don't think we
should ignore these points."

http://lists.llvm.org/pipermail/llvm-dev/2019-February/130311.html

"There is also a decent amount of code in Clang using foo_bar_baz. ::shrug::

I think the amount of all of these pales in comparison to LLDB, and I think
generally all of these are not going to significantly change the total cost
of transition."

http://lists.llvm.org/pipermail/llvm-dev/2019-February/130309.html

"I think the fact that named things are called does not fully disambiguate
what they are.

I'm not trying to say that the collision with functions is *as* confusing
as that of colliding with types. Merely that both seem confusing. And I
find `foo_bar_baz` and `fooBarBaz` basically equivalent[1]. So between
those equivalents, I would choose the one with fewer collisions.

[1]: Ok, not quite, but I find this to be a more personal preference and am
trying to weight it lower as a consequence. I find functions much more
similar to types -- they are manifest properties of the program. I find
`FooBarBaz` and `fooBarBaz` to be very similar looking. There is *a*
distinction, but it is a minor one. I would prefer a greater visual
difference for variables, which `foo_bar_baz` provides."

Forgive me if I missed a post, it's a long thread.  :)

>From the above, I conclude that you prefer lower_case because LLDB uses
it and it's different from everything else other projects use.  Which I think
is basically what I summarized as the arguments I've read.

I'm still pretty puzzled why distinguishing functions/callables from "variables"
via under_scores or someCamelCase matters.  I guess I believe that with good
names and program structure (small functions, etc.) things should be fairly
clear.  I'm actually fine with CamelCase for variables (the current convention)
as I haven't found myself confused by it, but I understand why people want to
reserve that for types.

What's the process for making this kind of change?  If we want significant buy-in
from the community how do we get that?

                                     -David
________________________________________
From: Chandler Carruth <chandlerc at gmail.com>
Sent: Monday, February 25, 2019 4:47 PM
To: David Greene
Cc: paul.robinson at sony.com; llvm-dev at lists.llvm.org; nd at arm.com; asb at lowrisc.org
Subject: Re: [llvm-dev] RFC: changing variable naming rules in LLVM codebase

On Mon, Feb 25, 2019 at 7:17 AM David Greene via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
<paul.robinson at sony.com<mailto:paul.robinson at sony.com>> writes:

>> "lower_case" is a pretty drastic change from CamelCase and camelCase.
>> So far the only argument for it I've seen is, "lldb uses it all over the
>> place."  Having one subproject drive the standard for everything else
>> seems backward.  It's certainly possible I missed other opinions on this
>> though.
>
> You have. For example, here's a "significant improvement" comment:
> http://lists.llvm.org/pipermail/llvm-dev/2019-February/130214.html

But I see nothing there about *why* it would be a "significant
improvement."  At best I see an allusion to something like, "this is
really different than anytyhing we've done before so it doesn't conflict
with any existing naming."  If I've misinterpreted I hope Chandler will
correct me.

I wrote more details on this thread about why I significantly prefer this. Can you respond there? I don't want to just repeat things that already make sense or miss the things that actually don't make sense.