[llvm-dev] changing variable naming rules in LLVM codebase (original) (raw)

Chandler Carruth via llvm-dev llvm-dev at lists.llvm.org
Mon Feb 18 17:29:58 PST 2019

On Wed, Feb 13, 2019 at 6:02 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.

There is also a decent amount of code in Clang using foo_bar_baz. ::shrug::

I think the amount of all of these pales in comparison to LLDB, and I think generally all of these are not going to significantly change the total cost of transition.

-Chandler

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 underscorenames 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/20190218/134b7b1a/attachment.html>

More information about the llvm-dev mailing list