llvm dev - Feb 2019 - changing variable naming rules in LLVM codebase

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>

There is of course some amount of llvm and clang code which already uses
initialLowerCaseNames for variable names too, contrary to the style guide.
I don't know how to easily quantify how much.

E.g. ParseGNUAttributes in clang/include/clang/Parse/Parser.h is one I
noticed.


On Wed, Feb 13, 2019 at 2:49 PM Zachary Turner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190213/fd961068/attachment.html>

I have to agree with Paul that I think it is rather useful to have a naming
convention that distinguishes class members from locals, etc. I'm not sure
what that would look like, whether an m prefix for data members would be
something others would entertain, but something that makes it clear would
probably be useful. To use Paul's example, I think that mTheStuff vs.
TheStuff makes it super easy to visually identify what this is. I imagine
this wasn't mentioned in this thread or previously adopted because of some
good reason I am not aware of.
A more minor point about underscores vs camel case - what I like about
camel case is that it generally keeps my fingers on the 3 rows of the
keyboard I use the most. From an ergonomics perspective, I find typing a
whole lot of underscores a bit unnatural. So since I find camel case easier
to type and equally as readable, I would favour it over underscores.

On Wed, Feb 13, 2019 at 11:03 PM James Y Knight via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> There is of course some amount of llvm and clang code which already uses
> initialLowerCaseNames for variable names too, contrary to the style guide.
> I don't know how to easily quantify how much.
>
> E.g. ParseGNUAttributes in clang/include/clang/Parse/Parser.h is one I
> noticed.
>
>
> On Wed, Feb 13, 2019 at 2:49 PM Zachary Turner via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> 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
>>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190214/8add1239/attachment.html>

On Wed, Feb 13, 2019 at 6:02 PM James Y Knight via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> There is of course some amount of llvm and clang code which already uses
> initialLowerCaseNames for variable names too, contrary to the style guide.
> I don't know how to easily quantify how much.
>
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.

-Chandler

>
> E.g. ParseGNUAttributes in clang/include/clang/Parse/Parser.h is one I
> noticed.
>
>
> On Wed, Feb 13, 2019 at 2:49 PM Zachary Turner via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> 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
>>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190218/134b7b1a/attachment.html>