<div dir="ltr">For lambdas, you have more contexts to confuse yourself, so why would a discriminator like '_' not be helpful here?<div><br></div><div>David</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 13, 2014 at 5:10 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Mon, Oct 13, 2014 at 4:42 PM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Mon, Oct 13, 2014 at 4:25 PM, Xinliang David Li <span dir="ltr"><<a href="mailto:xinliangli@gmail.com" target="_blank">xinliangli@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On Mon, Oct 13, 2014 at 4:00 PM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>></span> wrote:<br></span><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Oct 13, 2014, at 3:44 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>> wrote:<br>
> I actually have a particular allergy to member variable names and function names having similar styles:<br>
><br>
> bool x = i->isMyConditionTrue;<br>
><br>
> 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.<br>
<br>
</span>This is exactly why I was making the wishy-washy statement about instance variables.  This is the pattern that I tend to prefer:<br>
<br>
<br>
class Something {<br>
  bool IsMyConditionTrue;<br>
<br>
…<br>
<br>
  bool isMyConditionTrue() const { return IsMyConditionTrue; }<br>
}<br>
<br>
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 :-)<br></blockquote><div><br></div></span><div>trailing or leading _ for ivars seem to be a common practice. What is the reason it s not used in LLVM?</div></div></div></div></blockquote><div><br></div></span><div>[s/ivar/non-static data member/g; we're not using Objective-C ;-)]</div><div><br></div><div>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.)</div><div><br></div><div>Trailing _ is better, but still suffers from bugs where the wrong entity is used:</div><div><br></div><div>class A {</div><div>  bool m_;</div><div>  A(bool m) : m_(m_) {} // oops, but we diagnose</div><div>};<br></div><div><br></div><div>Capitalizing member names has the same problems as capitalizing local variable names:</div><div><br></div><div>struct MyRAIIThing {</div><div>  Sema &Sema; // =(</div><div>};</div></blockquote></div><br></div></div>In addition to all of this, I disagree that it is reasonable to try to differentiate between member and local variables.</div><div class="gmail_extra"><br></div><div class="gmail_extra">struct MyClass {</div><div class="gmail_extra">  static int x;</div><div class="gmail_extra">  int y;</div><div class="gmail_extra"><br></div><div class="gmail_extra">  void MyFunction(MyClass a, MyClass b) {</div><div class="gmail_extra">    int c;</div><div class="gmail_extra"><br></div><div class="gmail_extra">    std::sort(......, [] {</div><div class="gmail_extra">      std::ptrdiff_t d = ...;</div><div class="gmail_extra">      ++c;</div><div class="gmail_extra">      // ...</div><div class="gmail_extra">      f(a.x);</div><div class="gmail_extra">      g(x);</div><div class="gmail_extra">      h(y);</div><div class="gmail_extra">    });</div><div class="gmail_extra">  }</div><div class="gmail_extra">};</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div></div>
</blockquote></div><br></div>