[lldb-dev] LLDB Coding Style

[Zachary Turner]

It's already checked in.  It's not perfect yet, but it's close.  The way I
run it against only changes in a CL involves having a chromium checkout on
my disk (yea, wtf, i know), and I don't know how to do it otherwise.  Not
saying there's not a way, but I would ask over on cfe-dev or llvm-dev for
more info.


On Tue, Aug 19, 2014 at 11:14 AM, Sean Callanan <scallanan at apple.com> wrote:

> Please do forward that clang-format file when you have it put together.  I
> would love to have access to that.
>
> Sean
>
> On Aug 19, 2014, at 11:06 AM, Zachary Turner <zturner at google.com> wrote:
>
> Definitely agree with you on this.  I have no plans to go fixup old code,
> and I don't think others should either.  And if we see a change go through
> that does attempt to fix up old code, we should block it.
>
> That said, I'm working on a clang-format file that will automate this
> formatting for us (or at least, for me, should nobody else choose to use
> it), and I plan to run it against all my changelists before submitting
> them.  Note that this only reformats lines that have already been touched
> by the CL, so there's no risk of formatting-only changes making it in.
>
>
> On Tue, Aug 19, 2014 at 11:00 AM, Sean Callanan <scallanan at apple.com>
> wrote:
>
>> One point about this discussion, by the way.
>>
>> While I support adherence to a consistent style for new/changed code,
>> this should in no way be taken as support for going through and fixing
>> indentation/style on old code.
>> We have internal branches that become hell to merge when e.g. spacing has
>> been altered subtly, or brace depth is changed…
>> If we all do our part to clean the parts we’re touching, then I think
>> that will be enough to keep LLDB clean.
>>
>> Sean
>>
>> On Aug 19, 2014, at 10:16 AM, Zachary Turner <zturner at google.com> wrote:
>>
>> I brought this up in a thread on lldb-commits, but since it is of more
>> general interest, I want to make a thread here as well.
>>
>> Can we have clear direction on LLDB coding style?  Ideally in the form of
>> an update to lldb.llvm.org, but as that might require a little more
>> effort, even some details in a response to this thread would be a help.
>>  Some things I've deduced from looking at the code, and other things I'm
>> not so sure about, because of inconsistencies in the code or just no clear
>> rule.
>>
>> Indentation width: 4
>> Column limit: 140  (does this apply to comments too?  Most
>> function-declaration comments seem to wrap at 80)
>> Brace style: Allman
>>     if (foo)
>>     {
>>         // code here
>>     }
>>
>> Break after function return type: Always, only on declarations, only on
>> definitions, only in headers, or never?
>>
>> Space before function parentheses: When?
>>
>> Indent case labels inside switch: A or B below?
>>     switch (foo)
>>     {
>>         case A:
>>     case B:
>>     }
>>
>> Indent braces inside of a case: A or B below?
>>     switch (foo)
>>     {
>>         case A:
>>         {
>>         }
>>         case B:
>>             {
>>             }
>>     }
>>
>> Any other rules I should be cognizant of?
>>  _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140819/c73a188c/attachment.html>