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

[Kurt Schwehr]

+1 to Even's suggestion.

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


On Sun, May 27, 2018, 6:45 AM Even Rouault <even.rouault at spatialys.com>
wrote:

> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20180527/d7727e52/attachment.html>