[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Using clang-format for formatting our code
From: |
Hugo Melder |
Subject: |
Re: Using clang-format for formatting our code |
Date: |
Fri, 19 Aug 2022 19:42:24 +0200 |
I’ve written a basic .clang-format that inherits the GNU coding standards and
adds some additional Objc settings. Unfortunately, clang-format is incapable of
adding spaces before method arguments.
Has anyone an idea on how to fix this?
> On 16. Aug 2022, at 15:12, David Chisnall <gnustep@theravensnest.org> wrote:
>
>
> 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
>