[llvm-dev] changing variable naming rules in LLVM codebase
James Y Knight via llvm-dev
llvm-dev at lists.llvm.org
Wed Feb 13 20:02:23 PST 2019
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
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
>> > 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
>> function names is really a very weak argument. IME function names are
>> *incredibly* *hard* to confuse with anything else, because they *always*
>> surrounding syntactic context. Given `TheStuff->fooBar().getThingy()` is
>> even conceivable that you might not instantly get that fooBar and
>> 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
>> is a barrier to code-reading IME. Even renaming it to `stuff` would help
>> approximately zero percent. Parameter? Local? Class member? Global? LLVM
>> incredibly few globals for other reasons, but using the same convention
>> locals and class members is a real problem for code-reading, especially
>> operating in methods for classes you're not super familiar with.
>> I acknowledge that the current RFC doesn't propose a member naming
>> different from other variables, but IMO it really ought to. *That* is the
>> distinction that would really help in reading unfamiliar code.
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev