<div dir="ltr">I would slightly alter this recommendation depending on whether the codebase is currently in a reasonably consistent state (both internally and wrt. what clang-format would do).<div><br></div><div>The basic assumption is that code is easier to read if it is more consistent.</div>
<div><br></div><div>If the code base is currently inconsistently formatted, then a full reformatting might provide benefit. If it is significantly different from clang-format, then an incremental approach has the cost of making the code more inconsistent (at least temporarily).</div>
<div><br><div class="gmail_extra"><div class="gmail_quote">On Thu, Jan 9, 2014 at 12:03 PM, Manuel Klimek <span dir="ltr"><<a href="mailto:klimek@google.com" target="_blank" class="cremed">klimek@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">FYI, our usual recommendation is to use clang-format only on changed code, unless there's strong evidence that the cost of the initial reformatting is basically zero (which usually means a team / community is pretty unanimous about the decision).</div>
<div class="HOEnZb"><div class="h5">
<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 9, 2014 at 11:53 AM, Tobias Grosser <span dir="ltr"><<a href="mailto:tobias@grosser.es" target="_blank" class="cremed">tobias@grosser.es</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Manuel, Daniel,<br>
<br>
I forgot to CC you in this mail. The thread here may be interesting to you, also in the light of the last discussion we had.<span><font color="#888888"><br>
<br>
Tobias</font></span><div><div><br>
<br>
On 12/21/2013 12:00 AM, Tobias Grosser wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 12/20/2013 11:18 PM, Rafael Espíndola wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 20 December 2013 15:52, reed kotler <<a href="mailto:rkotler@mips.com" target="_blank" class="cremed">rkotler@mips.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We are considering running clang format on the whole Mips target.<br>
<br>
Is there any rule against this?<br>
</blockquote>
<br>
I don't think there is a rule, but even simpler things like "remove<br>
all trailing spaces" were not common in the past<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Is there any good argument against doing this even if there is no rule<br>
against it?<br>
</blockquote>
<br>
It think the argument was that it makes history harder to follow. A<br>
git blame lands you on the reformatting patch and you have to manually<br>
skip them.<br>
<br>
I don't personally consider that a strong argument and I think polly<br>
did just that (run clang-format on everything), so it might be OK<br>
these days.<br>
</blockquote>
<br>
Unfortunately for Polly it was not as clean as we started using<br>
clang-format early, so we had to format piece by piece the sections that<br>
clang-format could already handle.<br>
<br>
However, we now have an automatic clang-format buildbot so formatting<br>
became (in some way) a 'solved problem'.<br>
<br>
One benefit of fully formatted source code is that there is no need for<br>
any new patches to include 'formatting fixes', which previously<br>
sometimes obfuscated submitted patches and commits. In fact, patch<br>
reviews are now free of formatting discussions. If the patch passes<br>
make polly-check-format, it is ready to be discussed. (If it does not,<br>
make polly-update-format needs to be run). Also, having a single<br>
formatting commit to skip might arguably be easier, than to have a mixed<br>
history of formatting and patches.<br>
<br>
One reason that may hold us back from formatting all LLVM code is the<br>
risk of clang-format changing its formatting behavior. The only thing<br>
worse than formatting all code is formatting all code twice. ;)<br>
<br>
 From my experience with Polly, clang-format's formatting has been<br>
largely stable the last months. Changes in its formatting behavior have<br>
normally been fixed quickly. So it may make sense to format more code.<br>
I would still be afraid of formatting all LLVM, but maybe a backend is<br>
a reasonable sized chunk.<br>
<br>
Maybe Manual and Daniel have some experience in formatting a larger set<br>
of files.<br>
</blockquote>
<br>
<br>
<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div></div>