I don’t think we can completely get rid of the lldb coding conventions doc;
we’ll need this type of thing as long as we use swig:
* enumerations that might end up being in the lldb SB API's should all be
written like:
typedef enum EnumName
{
eEnumNameFirstValue,
eEnumNameSecondValue,
} EnumName;
This redundancy is important because the enumerations that find their way
through SWIG into Python will show up as lldb.eEnumNameFirstValue, so including
the enum name in the value name disambiguates them in Python.
Some directed questions about this proposal:
- Will we move to an 80 column limit?
- Will we move to camel case for variables?
- Will we stop putting m_ at the front of class ivars and g_ at the
front of globals?
- Will we stop using _sp and _up on the end of shared and unique
pointers?
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Zachary
Turner via lldb-dev
Sent: Thursday, August 11, 2016 1:37 PM
To: Jim Ingham <jing...@apple.com>
Cc: Kate Stone <k8st...@apple.com>; LLDB <lldb-dev@lists.llvm.org>
Subject: Re: [lldb-dev] LLDB Evolution
I was thinking the same thing too. I figured this was just for the interim.
Chris, did you mean to update the global LLVM style conventions?
On Thu, Aug 11, 2016 at 11:27 AM Jim Ingham <jing...@apple.com
<mailto:jing...@apple.com> > wrote:
Shouldn't this be made general and added to the llvm coding conventions? I was
assuming that upon completion of this exercise, we would delete the lldb coding
conventions doc.
Jim
> On Aug 11, 2016, at 11:20 AM, Zachary Turner via lldb-dev
> <lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> > wrote:
>
> On Wed, Aug 10, 2016 at 10:37 PM Chris Lattner <clatt...@apple.com
> <mailto:clatt...@apple.com> > wrote:
>
>> On Aug 9, 2016, at 3:01 PM, Zachary Turner via lldb-dev
>> <lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> > wrote:
>>
>> So perhaps it would be reasonable for us to standardize on something like
>> this:
>>
>> • Main Module Header
>> • Local/Private Headers
>> • lldb/...
>> • llvm/...
>> • System #includes
>
> This makes sense to me, and matches what clang does as well. I think that
> this is clearly in the spirit of the llvm include order standards, and I
> think it would be great to make this explicit in the coding standard doc.
> Can you send in a patch to update it to make this explicit? I’ll review it.
>
> -Chris
>
> I actually just submitted the patch. (Sorry, itchy trigger finger or
> something). r278373. If you have any comments let me know and I'm happy to
> iterate on it.
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
