[LLVMdev] RFC: variable names

[Chandler Carruth]

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/65b70fae/attachment.html>