[llvm-dev] changing variable naming rules in LLVM codebase
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
> 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*
> 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
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. So between
those equivalents, I would choose the one with fewer collisions.
: 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
> is a barrier to code-reading IME. Even renaming it to `stuff` would help
> approximately zero percent. Parameter? Local? Class member? Global? LLVM
> incredibly few globals for other reasons, but using the same convention
> locals and class members is a real problem for code-reading, especially
> operating in methods for classes you're not super familiar with.
> I acknowledge that the current RFC doesn't propose a member naming
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev