<div dir="auto">+1 to Even's suggestion.<div dir="auto"><br></div><div dir="auto">The default is the least complicated setup. And you can always turn off formatting for small blocks that really need special formatting. E.g. a matrix</div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, May 27, 2018, 6:45 AM Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> For this reason I would ask that some of the<br>
> C++ experts in the community come up with a set of coding guidelines for<br>
> the C++ parts of the code base. Lately the lack of code formatting<br>
> conventions in PROJ has been frustrating to several contributors. With the<br>
> addition of the new C++ parts of the code we have the chance to at least<br>
> include conventions for the C++ code. I know this has been a topic for GDAL<br>
> recently and since we have a big overlap with the GDAL community perhaps we<br>
> can benefit from their experiences. Kurt and Even, I believe you’ve been<br>
> involved in improving the GDAL code formatting rules, would one of you be<br>
> willing to suggest something that we can use in PROJ? A good starting<br>
> point, I guess, would be<br>
> <a href="https://trac.osgeo.org/gdal/wiki/rfc69_cplusplus_formatting" rel="noreferrer noreferrer" target="_blank">https://trac.osgeo.org/gdal/wiki/rfc69_cplusplus_formatting</a>.<br>
> <br>
<br>
One possibility would be to claim "this project has no particular C++ code <br>
formating rules. Do reasonable things [1]". But I'm afraid that won't be <br>
enough.<br>
<br>
I've experimented a bit with the suggested clang-format. Basically why not <br>
just using it in its default setup (LLVM style), without a particular .clang-<br>
format ?<br>
<br>
And have a scripts/autoformat.sh [2], to autoreformat things. Travis-CI could <br>
run it, and bail out if a file has been reformatted.<br>
<br>
Equivalently to my above adhoc script, I also see there is a 'git clang-<br>
format' tool that automatically runs clang-format on files that have been git <br>
added. Actually when testing it it seems to run it only on the parts you <br>
changed, probably to avoid causing code churn in non-modified parts: cf <br>
<a href="https://electronjs.org/docs/development/clang-format" rel="noreferrer noreferrer" target="_blank">https://electronjs.org/docs/development/clang-format</a><br>
<br>
That said there might be a slight risk of output instability depending on the <br>
clang-format version. I've tried with the one of LLVM 3.7, 3.8 and 7dev<br>
The good news is that the output of 3.8 and 7dev is identical on the .cpp <br>
files I've sketched.<br>
<br>
There was a difference with 3.7 and later versions regarding include sorting <br>
header (with 3.7, in foo.cpp, include "foo.h" must come first, whereas later <br>
versions insist on includes being sorted, accepting as an exception that <br>
"foo.h" is first, probably for compat with 3.7...). But 3.7 can probably be <br>
considered ancient, so let's aim for >= 3.8<br>
<br>
Even<br>
<br>
[1] Reminds me of road signs in Montana "Drive at reasonable speed"...<br>
<br>
[2]<br>
<br>
#!/bin/sh<br>
set -eu<br>
clang-format $1 > $1.reformatted<br>
if diff -u $1.reformatted $1; then<br>
# No reformatting: remove temporary file<br>
rm $1.reformatted<br>
else<br>
# Differences. Backup original file, and use reformatted file<br>
cp $1 $1.before_reformat<br>
mv $1.reformatted $1<br>
fi<br>
<br>
<br>
<br>
-- <br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" rel="noreferrer noreferrer" target="_blank">http://www.spatialys.com</a><br>
</blockquote></div>