<div dir="ltr"><div dir="ltr">On Tue, 10 Aug 2021 at 09:32, MyDeveloper Day via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.<br></div><div class="gmail_quote"><div>Anyone who knows me, knows I'm very much pro "clang-format all the things"<br></div></div></div></blockquote><div><br></div><div><div>I agree with most of the sentiment in this thread, too. clang-format can be dangerous but it can also be so much more. </div><div><br></div></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>Another problem of clang-format is that there are so many options but not many people know enough of them.</div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>cheers,<br></div><div>--renato</div></div></div>