[LLVMdev] RFC: variable names

[Richard Smith]

On Mon, Oct 13, 2014 at 5:01 PM, Xinliang David Li <xinliangli at gmail.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
>>
>
>
> Is the bug easier to spot with trailing _ ? It just stands out better in
> certain contexts.
>

That particular bug is "impossible" if you use the same name for the
parameter and the member. (You get a different class of bugs instead, and
of course you could typo one of the names and still hit this bug.)

David
>
>
>
>
>> };
>>
>> 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/293ff9c9/attachment.html>