[lldb-dev] LLDB Coding Style

[Daniel Jasper]

No. The diff is the input, but it uses it to determine file ranges and then
formats the actual files.


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

> That appears to only work against a diff though.  Which means I would have
> to generate a diff, format it, reset my HEAD back to before I generated the
> diff, then re-apply it.  Is there nothing that just operates directly on
> the repo?
>
>
> On Tue, Aug 19, 2014 at 11:38 AM, Daniel Jasper <djasper at google.com>
> wrote:
>
>> 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/a179d6ab/attachment.html>