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

[Sean Callanan via lldb-dev]

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 kth 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 <mailto: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 <mailto: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 <mailto: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

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