[lldb-dev] LLDB Evolution

[Greg Clayton via lldb-dev]

> On Aug 11, 2016, at 12:19 PM, Ted Woodward via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> 
> 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;

Space and comment formatting can take place in the API section, but nothing public facing can be renamed in any way. We have an API we have vended, so there will be no naming changes in the API and this extends to the enumerations as well. We will need to ensure nothing bad happens during the formatting.

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

Yes that is part of this.

> -          Will we move to camel case for variables?

Not as part of the first changes.

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

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

>  
> --
> 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-bounces at lists.llvm.org] On Behalf Of Zachary Turner via lldb-dev
> Sent: Thursday, August 11, 2016 1:37 PM
> To: Jim Ingham <jingham at apple.com>
> Cc: Kate Stone <k8stone at apple.com>; LLDB <lldb-dev at 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 <jingham at 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 at lists.llvm.org> wrote:
>> >
>> > On Wed, Aug 10, 2016 at 10:37 PM Chris Lattner <clattner at apple.com> wrote:
>> >
>> >> On Aug 9, 2016, at 3:01 PM, Zachary Turner via lldb-dev <lldb-dev at 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 at lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev