[LLVMdev] RFC: variable names

Chandler Carruth chandlerc at google.com
Mon Oct 13 16:14:41 PDT 2014

On Mon, Oct 13, 2014 at 4:08 PM, Richard Smith <richard at metafoo.co.uk>

> I think this would be bad:
>   function();
>   lambda();
>   longFunction();
>   long_lambda();
> ... but possibly not in practice, since function names rarely have only
> one word.
> A partial-camel-case, partly-underscores convention sounds strange to me.
> (I don't find this to be problematic for BIG_SCARY_MACROS and for
> ABCK_EnumNamespaces because the former are rare and in the latter case the
> underscore isn't a word separator, it's a namespace separator.) We have a
> few people here who are used to such a style (since it's what the Google
> style guide and derivatives uses); any useful feedback from that experience?

This has never come up as a practical problem in my time at Google. Or at
least, if it has, it was so rare and long ago that I can't remember it. I
don't expect it to be a problem in practice. Mostly that is because all of
the problematic cases have two words in them, with one of the words often
being "is" or a related obvious verb like "get", "create", etc.

> Some arguments against the change as proposed:
> 1. Initialisms. It's common in Clang code (also in LLVM?) to use
> initialisms as variable names. This doesn't really seem to work for names
> that start with a lower case letter.

I think wee at least need a good answer to this.

> 2. The ambiguity introduced might be worse than the one removed. It's
> usually easy to see if a name is a type or variable from the context of the
> use. It's not so easy to see if a name is a function or a variable,
> especially as more variables become callable due to the prevalence of
> lambdas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141013/9860f890/attachment.html>

More information about the llvm-dev mailing list