[lldb-dev] clang-format now supports return type on separate line

[Todd Fiala via lldb-dev]

Jim, I think you and I have talked about this in the past.  Care to comment?

On Thu, Jan 21, 2016 at 11:18 AM, Sean Callanan <scallanan at apple.com> wrote:

> I tend to agree with Zachary on the overall principle – and I would be
> willing to clang-format functions when I modify them.  I’m concerned about
> a specific class of functions, though.  Let’s say I have a function that
> has had lots of activity (I’m thinking of, for example, ParseType off in
> the DWARF parser).  Unfortunately, such functions tend to be the ones that
> benefit most from clang-format.
>
> In such a function, there’s a lot of useful history available via svn
> blame that helps when fixing bugs.  My concern is that if someone
> clang-formats this function after applying the *k*th fix, suddenly I've
> lost convenient access to that history.  It’s only available with a fair
> amount of pain, and this pain increases as more fixes are applied because
> now I need to interleave the info before and after reformatting.
>
> Would it be reasonable to mark such functions as “Don’t clang-format”?
> That could be also interpreted as a “// TODO add comments so what this does
> is more understandable”
>
> Sean
>
> On Jan 21, 2016, at 10:59 AM, Zachary Turner via lldb-dev <
> lldb-dev at lists.llvm.org> wrote:
>
> Also this is the same standard that applies to the rest of LLVM.
>  clang-format your patches.  Just because we haven't been consistently
> following the rules until now doesn't mean we should continue to not follow
> the rules going forward.  This way eventually the codebase slowly converges
> towards a properly formatted one.  If clang-format does something that you
> think looks awkward with respect to the surrounding code (perhaps within a
> single logical block or whatever else) then just touch a line of code in
> the surrounding area so that clang-format will do it too. Since it only
> formats the differential, you have as much control as you need to produce
> something that a) is consistent with the rules, and b) doesn't look awkward
> with respect to surrounding code.
>
> On Thu, Jan 21, 2016 at 10:11 AM Zachary Turner <zturner at google.com>
> wrote:
>
>> I'm not sure I agree.  I don't think anything will be awkwardly formatted
>> with regards to the rest of the file.  The biggest thing this is going to
>> fix are whitespace at the end of lines, line breakign conventions, and
>> space between function name and parentheses.
>>
>> If we're not going to enforce a coding style, why have one at all?
>>  clang-format enforces it.
>>
>> On Thu, Jan 21, 2016 at 8:41 AM Todd Fiala <todd.fiala at gmail.com> wrote:
>>
>>> Glad to see clang-format getting some improvements.
>>>
>>>
>>>
>>> On Thu, Jan 7, 2016 at 10:30 AM, Zachary Turner <zturner at google.com>
>>> wrote:
>>>
>>>> As far as I'm aware, this is the last major incompatibility between
>>>> LLDB's style and clang-format's feature set.
>>>>
>>>> I would appreciate it if more people could try it out with a few of
>>>> their patches, and let me know if any LLDB style incompatibilities arise in
>>>> the formatted code.
>>>>
>>>> I would eventually like to move towards requiring that all patches be
>>>> clang-formatted before committing to LLDB.
>>>>
>>>
>>> Question to the group on that last part.  I think if we have a large
>>> body of code that is just getting a few tweaks to a method, having the
>>> patch run through the formatter could lead to some pretty ugly code.
>>> Imagine a few lines of a file awkwardly formatted related to the rest of
>>> the file.  Since we're not trying to reformat everything at once (which
>>> makes for difficult code traceability), and given there was a large code
>>> base to start with before LLDB was part of LLVM, I'm not sure we want a
>>> blanket statement that says it must go through clang-format.  (I personally
>>> would be fine with doing whole new functions and other logical blocks of
>>> code via clang-format when inserted into existing code, but I think it
>>> probably extreme when we're talking about new little sections within
>>> existing functions).
>>>
>>> Thoughts?
>>>
>>>
>>>
>>> --
>>> -Todd
>>>
>> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
>


-- 
-Todd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160121/878bec9d/attachment-0001.html>