[LLVMdev] RFC: variable names

[Xinliang David Li]

For lambdas, you have more contexts to confuse yourself, so why would a
discriminator like '_' not be helpful here?

David

On Mon, Oct 13, 2014 at 5:10 PM, Chandler Carruth <chandlerc at google.com>
wrote:

>
> On Mon, Oct 13, 2014 at 4:42 PM, Richard Smith <richard at metafoo.co.uk>
> wrote:
>
>> On Mon, Oct 13, 2014 at 4:25 PM, Xinliang David Li <xinliangli at gmail.com>
>> wrote:
>>
>>> On Mon, Oct 13, 2014 at 4:00 PM, Chris Lattner <clattner at apple.com>
>>> wrote:
>>>
>>>> On Oct 13, 2014, at 3:44 PM, Chandler Carruth <chandlerc at google.com>
>>>> wrote:
>>>> > I actually have a particular allergy to member variable names and
>>>> function names having similar styles:
>>>> >
>>>> > bool x = i->isMyConditionTrue;
>>>> >
>>>> > Did I mean to write 'isMyConditionTrue()'? Or 'bool &x =
>>>> I->isMyConditionTrue'? Or something else? I have no idea. Warnings and
>>>> other things can help reduce the likelihood of this becoming a live bug,
>>>> but it still makes the code harder to read IMO.
>>>>
>>>> This is exactly why I was making the wishy-washy statement about
>>>> instance variables.  This is the pattern that I tend to prefer:
>>>>
>>>>
>>>> class Something {
>>>>   bool IsMyConditionTrue;
>>>>
>>>> …
>>>>
>>>>   bool isMyConditionTrue() const { return IsMyConditionTrue; }
>>>> }
>>>>
>>>> If you make instance variables be lower camel case, then you get
>>>> serious conflict between ivars and methods.  Doing this also deflates some
>>>> of the ammunition used by advocates of _ for ivars :-)
>>>>
>>>
>>> trailing or leading _ for ivars seem to be a common practice. What is
>>> the reason it s not used in LLVM?
>>>
>>
>> [s/ivar/non-static data member/g; we're not using Objective-C ;-)]
>>
>> Leading _ is incompatible with leading capital (it gives you a reserved
>> identifier and thus undefined behavior). I have seen this cause inscrutable
>> compilation failures in practice. (With Chandler's approach for initialisms
>> we may still get leading capitals.)
>>
>> Trailing _ is better, but still suffers from bugs where the wrong entity
>> is used:
>>
>> class A {
>>   bool m_;
>>   A(bool m) : m_(m_) {} // oops, but we diagnose
>> };
>>
>> Capitalizing member names has the same problems as capitalizing local
>> variable names:
>>
>> struct MyRAIIThing {
>>   Sema &Sema; // =(
>> };
>>
>
> In addition to all of this, I disagree that it is reasonable to try to
> differentiate between member and local variables.
>
> struct MyClass {
>   static int x;
>   int y;
>
>   void MyFunction(MyClass a, MyClass b) {
>     int c;
>
>     std::sort(......, [] {
>       std::ptrdiff_t d = ...;
>       ++c;
>       // ...
>       f(a.x);
>       g(x);
>       h(y);
>     });
>   }
> };
>
> Between arguments, lambda captures, non-static and static locals, I have
> no idea how to usefully distinguish between x, y, a, b, c and d here. I
> don't think it is meaningful to try. They are *all* variables.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141013/0c3da05b/attachment.html>