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