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

Chandler Carruth via llvm-dev llvm-dev at lists.llvm.org
Mon Feb 18 17:23:05 PST 2019

On Wed, Feb 13, 2019 at 6:52 AM <paul.robinson at sony.com> wrote:

Chandler wrote:

> FWIW, I'm pretty strongly opposed to humbleCamelCase. We already use that > style so something else. Presumably you are equally opposed to RegularCamelCase, because we already use that style for something else.

I would be opposed to going through the very significant cost of changing the naming convention, merely to end up there.

The convention we already use has a huge advantage of already being relatively consistent.

But really, objecting on the grounds that a given style is already used for function names is really a very weak argument. IME function names are incredibly hard to confuse with anything else, because they always have surrounding syntactic context. Given TheStuff->fooBar().getThingy() is it even conceivable that you might not instantly get that fooBar and getThingy are methods? Therefore, using the same convention for some other kind of name is Not Confusing.

I disagree FWIW... Lambdas (and callables generally) at the least make this ambiguous.

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.

OTOH, TheStuff comes out of nowhere with no clues to its origin, and

that is a barrier to code-reading IME. Even renaming it to stuff would help approximately zero percent. Parameter? Local? Class member? Global? LLVM has incredibly few globals for other reasons, but using the same convention for locals and class members is a real problem for code-reading, especially code operating in methods for classes you're not super familiar with.

I acknowledge that the current RFC doesn't propose a member naming convention different from other variables, but IMO it really ought to. That is the distinction that would really help in reading unfamiliar code.

I could see a lot of utility of this, but I do find it to be orthogonal.

--paulr -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190218/6024eef4/attachment.html>

More information about the llvm-dev mailing list