[LLVMdev] RFC: variable names (original) (raw)

Richard Smith richard at metafoo.co.uk
Mon Oct 13 17:07:30 PDT 2014

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>

More information about the llvm-dev mailing list