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 :-) -Chris
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.Agreed. I am also fine with: class Something { bool is_my_condition_true; ... bool isMyConditionTrue() const { return is_my_condition_true; } }; I think it has the same lack of ambiguity. Its somewhat nicer that there is no type name conflict as well, but honestly that's a smaller gain IMO. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141013/3ba16654/attachment.html>
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? David> > -Chris > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141013/f9c84ffe/attachment.html>
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>