llvm dev - Aug 2021 - [cfe-dev] [RFC] Adding support for clang-format making further code modifying changes

On Tue, 10 Aug 2021 at 09:32, MyDeveloper Day via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> I feel this is something that clang-format could be made to easily handle.
> This RFC is about gaining a general consensus to let us try. We feel we can
> add even more value.
> Anyone who knows me, knows I'm very much pro "clang-format all the
things"
>
I agree with most of the sentiment in this thread, too. clang-format can be
dangerous but it can also be so much more.

I have been using clang-format on editors, pre-commit checks and ninja
targets for a quite a while and I think it's a fundamental development
tool. With it, style comments stop being a personal conversation and become
tooling.

I would like to see a world where there are no more long styling documents
with personal angst in all projects, just a clang-format config file.

I'm in favour of increasing the potency of clang-format. Quick checks can
be done on save, more expensive ones as ninja targets and even more
expensive ones as CI.

To me, the discussion of defaults and perils must be clear to all users and
documentation may not be the best way: I've never read the clang-format
documentation.

Another problem of clang-format is that there are so many options but not
many people know enough of them.

Yet another problem of clang-format is that its behaviour is different for
the same options over different versions. We're stuck on clang-format-9,
not because it's "the best" but because re-formatting the whole
tree every
time a new tool comes out is silly.

So a good solution to all of these problems is to generate a default
configuration file with all the options and comments on each one of them,
including "this changes non-whitespace code", "this is quite
slow", "if
this breaks code, here's how to fix", etc, and setting all of them to
the
default value.

We also nee to be able to update the config file with new options without
destroying the old (often modified) ones, and make sure new versions only
do new things if the config is different.

I know, configuration management and backwards compatibility aren't
trivial, but managing clang-format over time isn't either, and it should.
Well, it should, if it wants to be a catch-all tool to do all the things.

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210810/f89389b3/attachment.html>

On Tue, 10 Aug 2021, 12:10 Renato Golin via cfe-dev, <cfe-dev at
lists.llvm.org>
wrote:
> On Tue, 10 Aug 2021 at 09:32, MyDeveloper Day via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> I feel this is something that clang-format could be made to easily
>> handle. This RFC is about gaining a general consensus to let us try. We
>> feel we can add even more value.
>> Anyone who knows me, knows I'm very much pro "clang-format all
the things"
>>
>
> I agree with most of the sentiment in this thread, too. clang-format can
> be dangerous but it can also be so much more.
>
> I have been using clang-format on editors, pre-commit checks and ninja
> targets for a quite a while and I think it's a fundamental development
> tool. With it, style comments stop being a personal conversation and become
> tooling.
>
> I would like to see a world where there are no more long styling documents
> with personal angst in all projects, just a clang-format config file.
>
> I'm in favour of increasing the potency of clang-format. Quick checks
can
> be done on save, more expensive ones as ninja targets and even more
> expensive ones as CI.
>
> To me, the discussion of defaults and perils must be clear to all users
> and documentation may not be the best way: I've never read the
clang-format
> documentation.
>
> Another problem of clang-format is that there are so many options but not
> many people know enough of them.
>
> Yet another problem of clang-format is that its behaviour is different for
> the same options over different versions. We're stuck on
clang-format-9,
> not because it's "the best" but because re-formatting the
whole tree every
> time a new tool comes out is silly.
>
> So a good solution to all of these problems is to generate a default
> configuration file with all the options and comments on each one of them,
> including "this changes non-whitespace code", "this is quite
slow", "if
> this breaks code, here's how to fix", etc, and setting all of them
to the
> default value.
>
> We also nee to be able to update the config file with new options without
> destroying the old (often modified) ones, and make sure new versions only
> do new things if the config is different.
>
> I know, configuration management and backwards compatibility aren't
> trivial, but managing clang-format over time isn't either, and it
should.
> Well, it should, if it wants to be a catch-all tool to do all the things.
>
clang-format is designed to run on changed lines, not to have all code be
compliant. You can use it for the latter, but I think it's a pretty
fundamental difference in development goals.

> cheers,
> --renato
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210810/421726d5/attachment.html>