Re: Using clang-format for formatting our code

[David Chisnall]

On 16/08/2022 11:18, Richard Frith-Macdonald wrote:
> > On 16 Aug 2022, at 10:25, Hugo Melder <admin@hugomelder.com> wrote:
> >
> > Hi,
> >
> > Having a consistent code style is useful both for reading and writing code, 
> > especially for contributors. The GNUstep base framework currently has a 
> > .clang-format configuration file in the project root, but is not used. We could 
> > use a configuration file from major Objective-C open source projects like 
> > WebKit, or define our own formatting guidelines.
> >
> > What is your opinion towards strict code formatting?
>
> We have a coding/formatting style defined in the GNUstep base documentation 
> (coding-standards.texi), and we try to make everything conform to that standard.
>
> However, I prefer *not* to refuse contributions based on stylistic deviations.  
>  Rather I would prefer to thank the contributor, correct any issues, and 
> encourage use of the standard format in future contributions.
>
> If the .clang-format could be fixed to implement the GNUstep coding style, it 
> might be useful for those of us who have it installed.

From using clang-format in some other projects:

 - Having a machine-applied style is a huge improvement, it avoids any 
discussion of style in code review (aside from naming of things. 
clang-tidy can help a bit there) and is a big win for folks who are 
moving between projects with different styles.

 - There's some initial pain for anyone downstream after the first time 
that you apply it, but this is reduced later on.  Some editors will 
automatically format things with a .clang-format style and this can 
cause downstream people to introduce accidental diffs if a .clang-format 
exists and isn't used.

 - Different versions of clang-format produce slightly different 
output.  It's worth picking a version and keeping it as the default for 
a few years and then moving forward.

 - Enforcing clang-format compliance on PRs with github actions is easy 
and means that you never have to review inconsistently formatted code.

David