<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:56.7pt 42.5pt 56.7pt 85.05pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">For what it’s worth, I’ve definitely been in situation where I’ve wondered whether some variable is a member or not (i.e. local or function argument). Especially if I wasn’t using IDE and was looking at an unfamiliar code.<br>
It usually wasn’t hard to resolve but it incurred a “context switch” penalty.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Never personally had a problem with short one letter_ prefixes. You don’t need to pronounce them or treat them like part of the name. Similarly to how you don’t need to underscores.<br>
<br>
That’s obviously just my opinion (and I’m just starting to get familiar with LLVM code base). Also, pervasiveness of acronyms was bigger obstacle in reading new code, in my experience.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">--<o:p></o:p></p>
<p class="MsoNormal">Danila<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>From:</b> llvm-dev [mailto:llvm-dev-bounces@lists.llvm.org]
<b>On Behalf Of </b>James Henderson via llvm-dev<br>
<b>Sent:</b> Tuesday, February 19, 2019 13:35<br>
<b>To:</b> David Greene <dag@cray.com><br>
<b>Cc:</b> llvm-dev <llvm-dev@lists.llvm.org><br>
<b>Subject:</b> Re: [llvm-dev] changing variable naming rules in LLVM codebase<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">+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).<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">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:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwMFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=YgdxWMcdqQPlU9EdetI-xI79G7ouw9_Us0dFsZnFQYU&m=Bc4TyFELdmSvEfyclmOxgnmIVz77esXhMlo3GnaxMYg&s=JnDKvQ81TWtmJE7cB2qNOZxqazDnhLc2O2yiuJYno3w&e=" 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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwMFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=YgdxWMcdqQPlU9EdetI-xI79G7ouw9_Us0dFsZnFQYU&m=Bc4TyFELdmSvEfyclmOxgnmIVz77esXhMlo3GnaxMYg&s=JnDKvQ81TWtmJE7cB2qNOZxqazDnhLc2O2yiuJYno3w&e=" 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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwMFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=YgdxWMcdqQPlU9EdetI-xI79G7ouw9_Us0dFsZnFQYU&m=Bc4TyFELdmSvEfyclmOxgnmIVz77esXhMlo3GnaxMYg&s=JnDKvQ81TWtmJE7cB2qNOZxqazDnhLc2O2yiuJYno3w&e=" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</body>
</html>