<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 11, 2016, at 3:40 PM, Zachary Turner via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" class="">lldb-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Thu, Aug 11, 2016 at 3:28 PM Greg Clayton <<a href="mailto:gclayton@apple.com" class="">gclayton@apple.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="">
> - Will we stop putting m_ at the front of class ivars and g_ at the front of globals?<br class="">
<br class="">
I believe these make things much clearer and I would love to see llvm and clang adopt some way to identify member variables. "m_" might be too long, but at least a leading "_" would be nice. I don't think there is anything in the LLVM coding conventions that mentions how to name member variables is there?<br class=""></blockquote><div class="">Unfortunately there is. The LLVM rule is: everything is camel case. member variables, local variables, global variables, it's all the same. And that also means you can't distinguish between members, globals, and locals by looking at them because there's no difference. I don't think anyone is particularly fond of that rule, but it is what it is. It's one of those things where I really wish the LLVM rule was different (and I think everyone else does too), but it's followed regardless. I'm not opposed to doing something different, but if we do we should minimize that difference as much as possible. Note that _ followed by an uppercase letter are reserved identifiers in C++. So if we're going to veer from LLVM here, maybe camel case *followed* by an _ would be a reasonable compromise.</div><div class=""> </div></div></div></div></blockquote><br class=""></div><div>I recommend approaching this in three steps: </div><div><br class=""></div><div>1) get the less-controversial changes done that Greg was outlining.</div><div>2) start a discussion in the llvm community about the concept of a member/global prefix.</div><div>2a) the community could agree that llvm-as-a-whole should move to prefixes or otherwise change the camel case policy.</div><div>2b) the community could agree that the existing policies are preferred</div><div>3) LLDB moves to whatever is the end result of the discussion.</div><div><br class=""></div><div>I guess what I’m saying is that since the opinions about this are very strong, and because we haven’t really had that debate in the LLVM community, that it would be bad to proactively move to the LLVM style, simply to have to move back later. Iff the (sure to be extensive) community discussion settles on the idea that prefixes are the wrong thing, then LLDB should remove them to be consistent.</div><div><br class=""></div><div>-Chris</div><br class=""></body></html>