(original) (raw)

On Mon, Oct 13, 2014 at 4:42 PM, Richard Smith <richard@metafoo.co.uk> wrote:

On Mon, Oct 13, 2014 at 4:25 PM, Xinliang David Li <xinliangli@gmail.com> wrote:

On Mon, Oct 13, 2014 at 4:00 PM, Chris Lattner <clattner@apple.com> wrote:

On Oct 13, 2014, at 3:44 PM, Chandler Carruth <chandlerc@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; // =(

};