[llvm-dev] RFC: changing variable naming rules in LLVM codebase (original) (raw)

David Greene via llvm-dev llvm-dev at lists.llvm.org
Mon Feb 25 18:52:53 PST 2019

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 lowercase 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:

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

More information about the llvm-dev mailing list