[GRASS-dev] Proposal for using ClangFormat, replacing GNU indent, for C/C++ code formatting

[Nicklas Larsson]

> On 7 Dec 2022, at 02:51, Vaclav Petras <wenzeslaus at gmail.com> wrote:
> 
> 
> 
> On Mon, 5 Dec 2022 at 08:07, Nicklas Larsson via grass-dev <grass-dev at lists.osgeo.org <mailto:grass-dev at lists.osgeo.org>> wrote:
> 
> 1. We adapt the formatting policy using ClangFormat.
> 
> +1
> 
> I would prefer if formatting changes from GNU indent which can be done separately are done separately.

I don’t quite follow you.


> For Python & Black, I did that together but 1) in multiple PRs and 2) we lacked any formatting, so it was a little different. Things like ReflowComments seem like a good second round. (Sorry, I'm a little confused about your intention with unused .clang-format and what will be in there.) 


My intention is simple. First agree on style and add the .clang-format file to source and only after that start the actual formatting work.

I strongly advice to make visual supervision on formatting changes before merging. For that reason alone the whole source base should be formatted in batches of about 500 files each to be manageable. In total there are ca. 3360 files. The directories ‘include’ and ‘lib’ may need special attention because of the Doxygen comments, all the other will be very easily processed. In all this will need some 5-8 PRs.


Directory     #files
____________________
lib             1199
include          103
db               120
display          109
general           67
imagery          379
misc              13
ps                84
raster           774
raster3d         100
temporal           1
utils              2
vector           408
visualization      2
====================
                3361

I’d say we should strive to limit the formatting changes of a single file to minimum, i.e. to 1 (as in one) time. Therefore any changes like ReflowComments should be done in one go. (Also, I’m happy to go through all those file once, but not twice.)


> 2. We implement "BreakBeforeBraces" rules according the "Stroustrup" style.
> 
> 
> Related to that, the in-line comments in the PR are modified to have one space after the code while Black, i.e., our Python code, has two.

Well, the two are distinct different languages with different history. Black also imposes 88 col line width, not 80. I’d say we keep the ClangFormat defaults as long as there is no strong argument against. In the case with SpacesBeforeTrailingComments set to 1: do not forget that C-style comments take at least 6 characters!  E.g. `/* comment */`. And that is not even a Doxygen doc comment.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20221207/177439e6/attachment-0001.htm>