Then we have to explain it manually in code reviews for 3rd party contributors.
In my paid work project, where there is no time for perfect solutions because it’s a commercial thing, we set up a coding style that is acceptable given clang-format constraints. Then we have it integrated in our buildsystem, everyone just runs the “fix-format” script before pushing their changes for review, and there is 0 time spent in code review for style fixes, because whatever the tool decides to do is right, by definition.
This saves a ton of time. Then this time can be used for other code review aspects: reviewing the overall architecture of the code, checking for bugs, making sure the documentation is updated as needed, and so on.
If we have a tool that does only half the work, we lose that, we will still have to review that part manually, and need an extra round of review to get things right. Or several rounds, since there are no clear rules for this and we are unable to implement an automated formatter to do it, and so we can’t expect people who contribute for the first time to get it right by hand, either.
Given the choice of the two options nielx offered, I would take the automated formatting, and I will workaround the lack of readability by other means (for example, syntax highlighting in my text editor). However, if there is a “best of both worlds” option, where we have readable class declarations and a tool to automatically format them, I’ll take that. Even if the style is very different from what we have now. And I’m ready to compromise a little readability for a large improvement in code review flow and process, so I would accept a slightly less good formatting if it can be done by an automated tool.