[LLVMdev] RFC: variable names

[Chandler Carruth]

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

> 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>