[lldb-dev] LLDB Evolution

[Zachary Turner via lldb-dev]

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.


>
> > -          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.

Just my 2c though, we might be getting ahead of ourselves anyway since
we're not talking about variable renaming yet.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160811/749a8a12/attachment.html>