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

Tue Feb 19 02:34:33 PST 2019

+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).

On Tue, 19 Feb 2019 at 01:15, David Greene via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> That's interesting because I have always thought it strange to name
> members differently
> from other variables.  I guess in my mind if a local variable isn't easily
> identified as such,
> it's either declared much too far away from its use (the function is too
> large, is lacking
> proper scoping, whatever) or it is not well-named such as to denote its
> use.  Note that
> I specifically write, "denote its use" and not, "denote its scope."  Of
> course the poor
> naming could go the other way; naming a member "i," for example.
>
> I don't think I've ever come across a naming convention that treats
> function parameters
> specially.  Why?  Arguably they are as different from locals as members
> are, particularly
> when it comes to reference parameters.
>
> Slapping an "m_" in front of poorly-named members isn't really going to
> help much, any
> more than slapping an "l_" in front of local variables would.
>
> That said, I am certainly open to being convinced otherwise.
>
>                                                -David
>
> ________________________________________
> From: Nemanja Ivanovic <nemanja.i.ibm at gmail.com>
> Sent: Thursday, February 14, 2019 7:02:19 AM
> To: James Y Knight
> Cc: Zachary Turner; David Greene; llvm-dev
> Subject: Re: [llvm-dev] changing variable naming rules in LLVM codebase
>
> 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<mailto: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<mailto: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<mailto:
> 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<mailto: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<mailto: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/20190219/de70aa7d/attachment.html>