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

Richard Smith richard at metafoo.co.uk
Mon Oct 13 16:42:32 PDT 2014

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>

More information about the llvm-dev mailing list