<div dir="ltr"><div>+1 to David's statement that naming members and locals differently seems strange to me. I can't think of a case where it's been important for me to distinguish between a local and class member and it hasn't already been clear at a glance/click etc. Frankly, I just find turning things into non-English words (e.g. due to a prefix/suffix) strange and makes it harder for me to actually read/talk about code with people in person etc (e.g. try talking about the theoretical member variable mThing/m_thing with someone).<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 19 Feb 2019 at 01:15, David Greene via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">That's interesting because I have always thought it strange to name members differently<br>
from other variables.  I guess in my mind if a local variable isn't easily identified as such,<br>
it's either declared much too far away from its use (the function is too large, is lacking<br>
proper scoping, whatever) or it is not well-named such as to denote its use.  Note that<br>
I specifically write, "denote its use" and not, "denote its scope."  Of course the poor<br>
naming could go the other way; naming a member "i," for example.<br>
<br>
I don't think I've ever come across a naming convention that treats function parameters<br>
specially.  Why?  Arguably they are as different from locals as members are, particularly<br>
when it comes to reference parameters.<br>
<br>
Slapping an "m_" in front of poorly-named members isn't really going to help much, any<br>
more than slapping an "l_" in front of local variables would.<br>
<br>
That said, I am certainly open to being convinced otherwise.<br>
<br>
                                               -David<br>
<br>
________________________________________<br>
From: Nemanja Ivanovic <<a href="mailto:nemanja.i.ibm@gmail.com" target="_blank">nemanja.i.ibm@gmail.com</a>><br>
Sent: Thursday, February 14, 2019 7:02:19 AM<br>
To: James Y Knight<br>
Cc: Zachary Turner; David Greene; llvm-dev<br>
Subject: Re: [llvm-dev] changing variable naming rules in LLVM codebase<br>
<br>
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.<br>
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.<br>
<br>
On Wed, Feb 13, 2019 at 11:03 PM James Y Knight via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>> wrote:<br>
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.<br>
<br>
E.g. ParseGNUAttributes in clang/include/clang/Parse/Parser.h is one I noticed.<br>
<br>
<br>
On Wed, Feb 13, 2019 at 2:49 PM Zachary Turner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>> wrote:<br>
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.<br>
<br>
On Wed, Feb 13, 2019 at 8:52 AM <<a href="mailto:paul.robinson@sony.com" target="_blank">paul.robinson@sony.com</a><mailto:<a href="mailto:paul.robinson@sony.com" target="_blank">paul.robinson@sony.com</a>>> wrote:<br>
Chandler wrote:<br>
<br>
> FWIW, I'm pretty strongly opposed to humbleCamelCase. We already use that<br>
> style so something else.<br>
<br>
Presumably you are equally opposed to RegularCamelCase, because we already<br>
use *that* style for something else.<br>
<br>
But really, objecting on the grounds that a given style is already used for<br>
function names is really a very weak argument.  IME function names are<br>
*incredibly* *hard* to confuse with anything else, because they *always* have<br>
surrounding syntactic context. Given `TheStuff->fooBar().getThingy()` is it<br>
even conceivable that you might not instantly get that fooBar and getThingy<br>
are methods?  Therefore, using the same convention for some other kind of<br>
name is Not Confusing.<br>
<br>
OTOH, `TheStuff` comes out of nowhere with no clues to its origin, and *that*<br>
is a barrier to code-reading IME.  Even renaming it to `stuff` would help<br>
approximately zero percent. Parameter? Local? Class member? Global?  LLVM has<br>
incredibly few globals for other reasons, but using the same convention for<br>
locals and class members is a real problem for code-reading, especially code<br>
operating in methods for classes you're not super familiar with.<br>
<br>
I acknowledge that the current RFC doesn't propose a member naming convention<br>
different from other variables, but IMO it really ought to.  *That* is the<br>
distinction that would really help in reading unfamiliar code.<br>
--paulr<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>