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

Nemanja Ivanovic via llvm-dev llvm-dev at lists.llvm.org
Thu Feb 14 05:02:19 PST 2019

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>

More information about the llvm-dev mailing list