[lldb-dev] LLDB Coding Style

[Daniel Jasper]

Use clang-format-diff.py checked into cfe/tools/clang-format.


On Tue, Aug 19, 2014 at 11:25 AM, Zachary Turner <zturner at google.com> wrote:

> +djasper
>
> Ok, just for the record, here's what I do (for context, this discussion is
> about how to reformat the contents of an existing CL, without touching
> lines that were not modified by the CL).
>
> 1) Checkout chrome  (wtf right?  I'm sure there's a better workflow, I
> just don't know what it is.  djasper might though, which is why I've added
> him)
> 2) set the CHROMIUM_BUILDTOOLS_PATH environment variable to point to
> d:\src\chromium\src\buildtools   (update this for your situation)
> 3) Update PATH environment variable to point to the version of git that is
> in chrome's depot_tools
> 4) Commit some changes to my local git repo, but don't dcommit them yet.
> 5) git cl format
>
> This will look through your commit log and collect all the changes that
> are not upstreamed yet, and reformat those changes, leaving the result in
> your working copy.  For me, this is usually just a single commit that
> hasn't been upstreamed yet, so I just git commit --amend to add the
> formatting to it.
>
> I'm not sure how to do this without chrome's "git cl format" command.
>  Daniel?
>
>
> On Tue, Aug 19, 2014 at 11:13 AM, Todd Fiala <tfiala at google.com> wrote:
>
>> Hey Zach,
>>
>> It'd be great if you posted the command line you run to do that.  I'm
>> sure there are others (myself included) that would love to see how that
>> works.
>>
>> Thanks!
>>
>> -Todd
>>
>>
>> On Tue, 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
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> lldb-dev mailing list
>>> lldb-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>
>>>
>>
>>
>> --
>>  Todd Fiala | Software Engineer |  tfiala at google.com |  650-943-3180
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140819/661c681c/attachment.html>