[LLVMdev] RFC: variable names

[Richard Smith]

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; // =(
};
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141013/6a22494e/attachment.html>