<div dir="ltr">Hi,<div><br></div><div>Two things are crucial about clang-format:</div><div>1. clang-format is part of clang/llvm, so it's reusing parts of the same engine that parses the code on compilation;</div><div>2. clang-format ships git-clang-format that is able to format just a patch.</div><div><br></div><div>Even if committer has different clang-format version, if they use git-clang-format they'll change only the lines they would have edited anyway, so that situation with someone having incompatible version is not making things worse. In that it's majorly different from astyle way from years ago when it was a complete project reformat on every commit.</div><div><br></div><div>In PR Raul mentioned I'm reformatting all the code, but it doesn't have to be done in one go - I mostly wanted to test it's producing sane compiling output.<br></div><div><br></div><div>Minimal change is dragging in .clang-format from that PR and start routinely using it on commits.</div><div>Although I tried to match the lwgeom part's style, if we're adopting one of LLVM's supported ones we'll have a benefit of good existing testing coverage and familiarity to developers.</div><div>Here's the list: <a href="https://clang.llvm.org/docs/ClangFormatStyleOptions.html#configurable-format-style-options">https://clang.llvm.org/docs/ClangFormatStyleOptions.html#configurable-format-style-options</a> <br></div><div>Default, LLVM internal, one seems already much like the raster part - this way we don't need to store .clang-format file: <a href="https://llvm.org/docs/CodingStandards.html">https://llvm.org/docs/CodingStandards.html</a> </div><div><br></div><div>PostGIS lived without formatting for 8 years, so either formatter would have to format more than several tens of thousands lines if applied in one go, especially there are three distinct formatting styles already.</div><div><br></div><div>Sandro, are you looking on numbers from formatting just *.c files or *.c and *.h files?</div></div><br><div class="gmail_quote"><div dir="ltr">чт, 22 февр. 2018 г. в 21:37, Sandro Santilli <<a href="mailto:strk@kbt.io">strk@kbt.io</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Feb 22, 2018 at 07:05:14PM +0100, Sandro Santilli wrote:<br>
<br>
> QGIS (to look at close neighbours) used to ship their own version<br>
> of astyle to deal with it. Recently they introduced again ability<br>
> to use the system astyle, do we want to try that again ?<br>
> <a href="https://github.com/qgis/qgis/commit/c48e0069aee5360f71d3128a1f3c14775b7fb491" rel="noreferrer" target="_blank">https://github.com/qgis/qgis/commit/c48e0069aee5360f71d3128a1f3c14775b7fb491</a><br>
><br>
> QGIS now requires astyle 3.0+<br>
<br>
Just to give more info: the version of astyle that QGIS ships<br>
is 3.1, they just embed the full source code in qgis codebase.<br>
<br>
It only takes 664K:<br>
<br>
  664K    external/astyle/<br>
<br>
That'd be ~1% of the current PostGIS source code.<br>
I would not be against doing the same.<br>
<br>
--strk;<br>
_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a></blockquote></div>