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

[Zachary Turner via llvm-dev]

I want to reiterate the benefit that underscore_names would bring.  To be
clear it's not my favorite style, but it does have a very concrete
advantage which is that we have a very large subproject already using it.
it doesn't make sense to do a purely aesthetic move that not everyone is
going to agree on anyway, when we could do one with actual tangible value.

On Wed, Feb 13, 2019 at 8: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.
>
> 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.
>
> 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.
> --paulr
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190213/934259df/attachment.html>