> On Aug 11, 2016, at 3:40 PM, Zachary Turner <ztur...@google.com> wrote: > > > On Thu, Aug 11, 2016 at 3:28 PM Greg Clayton <gclay...@apple.com> wrote: > > > - Will we stop putting m_ at the front of class ivars and g_ at > > the front of globals? > > 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? > 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.
I don't really care about global variables, but member variables, I would love to still be able to tell them apart. If we go camel case, the maybe just a leading lower case "m". "m_foo" would become "mFoo"? > > > > - Will we stop using _sp and _up on the end of shared and unique > > pointers? > > Again, this makes things clearer in the code and I would prefer to keep these. > > Personally I've never been a fan of the _sp and _up suffixes, and they also > kind of clash with camel case naming. So if we move to camel case, then > seeing something like Debugger_sp is going to look really weird to me for a > variable name. Seems like we should just write DebuggerPtr or something. > Whether it's shared or unique or weak, meh. code completion tools can tell > you that kind of stuff I guess. If we go camel case then debugger_sp would become DebuggerSP. > > Just my 2c though, we might be getting ahead of ourselves anyway since we're > not talking about variable renaming yet. > Agreed. Lets start with 80 columns and the other formatting stuff to start with. > BTW, clang-tidy can find and fix variable naming style issues, so if we > decide to do this, there are still tools that can help us. Sounds good. _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
