(original) (raw)

On Wed, Feb 13, 2019 at 6:02 PM James Y Knight via llvm-dev <llvm-dev@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@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@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@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
LLVM Developers mailing list
llvm-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev