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>
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. 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/cf19fdd7/attachment.html>
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>
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>
> 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.You're too good a programmer. :-) If you'd shot yourself in the foot more often you might appreciate a convention that distinguishes between a transient local variable and one that is the same entity used by twelve other methods in the class. In this example I'd argue that x and y are meaningfully different things than a, b, c, and d. And, that if I see a lambda body that says ++c; f(a.x_); g(x_); h(y_); it's useful to know *just by looking at it* that c belongs to the function and x_ and y_ belong to the class instance. --paulr
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>