[lldb-dev] LLDB Coding Style

[Zachary Turner]

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/2ef05a7a/attachment.html>