[lldb-dev] LLDB Evolution

[Greg Clayton via lldb-dev]

> On Aug 11, 2016, at 3:40 PM, Zachary Turner <zturner at google.com> wrote:
> 
> 
> On Thu, Aug 11, 2016 at 3:28 PM Greg Clayton <gclayton at 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.