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

[Chandler Carruth via llvm-dev]

Also FWIW, I also like m_ prefix for member variables when combined with
lowercase_underscore naming.

*IF* it is worth going through the significant cost of switching, and we
have a plan to minimize the cost to developers reading inconsistent code.

On Thu, Feb 14, 2019 at 6:03 AM Zachary Turner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> fwiw, LLDB also uses m_ for member variables, so if we were to adopt an m
> prefix, then in conjunction with lowercase_underscore the entire codebase
> would be conforming.
>
> On Thu, Feb 14, 2019 at 5:02 AM Nemanja Ivanovic <nemanja.i.ibm at gmail.com>
> wrote:
>
>> 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
>>>
>> _______________________________________________
> 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/448a0d59/attachment.html>