[Proj] C++ formatting rules [was Re: Use of C++]

[Even Rouault]

> 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