[SUGGESTION] add .clang-format file to repo

[adamvm]

DISCLAIMERS TO SET EXPECTATIONS: I'm generally against language feature requests/changes unless they can be shown to improve simplicity, safety, or toolability in a quantifiable way. So:

• Please limit suggestions to quantifiable improvements to C++ simplicity, safety, or toolability. Quantifiable means that there is some kind of measurable data that helps motivate the change and measure success. Two of the big ones that will get my attention are eliminating vulnerabilities and eliminating guidance, so use those below please.
• Please do not suggest syntax changes. I accept there are hundreds of opinions and everyone will prefer something a little different. Syntax isn't the big thing, fixing semantics is -- reducing concept count, increasing toolability, are the big payoff.
• Please do not suggest things that amount to personal taste. I accept there are hundreds of personal tastes and everyone will prefer something a little different. For example, established stakes in the ground include that this declaration syntax is going to be left-to-right, and it's going to use : for every declaration and only for declarations.

Will your feature suggestion eliminate X% of security vulnerabilities of a given kind in current C++ code? If yes, please be specific about the classes of bugs that would go away, with an example or two (especially a link to a real CVE or two).

Will your feature suggestion automate or eliminate X% of current C++ guidance literature? If yes, please be specific about what current good guidance this helps make the default, and/or what guidelines we would no longer need to teach/learn or that would be simplified and how, with an example or two (especially a link to a real "Effective C++" or "C++ Core Guidelines" guideline or two). For ideas, you can refer to my CppCon 2020 talk starting at 10:31 where I summarize a categorized breakdown based on over 600 C++ guidance literature rules I cataloged and analyzed.

Describe alternatives you've considered.
There's nearly always more than one way to improve something. What other options did you consider? Why is the one you're suggesting better than those?
manual formating - human error prone, clang-format is widely used and do not force to use it

[JohelEGP]

manual formating - human error prone, clang-format is widely used and do not force to use it

This is the whole of the suggestion.
The rest is from the issue template.

Manual formatting is also resource-consuming.
That's why I consider it an essential tool to have.

I remember when I first discovered it.
I set it up with my preferences at the moment, and used "format on save".
I quickly noticed how I easily spent ~half the time writing new code just fiddling with formatting.
And that doesn't include time reformatting existing code.
Preferences change, and with Clang Format,
such change is centralized in the configuration file and easily reapplied to all code.

[Assyyn]

Do we have something yet? The code formatting looks very clean, would love to use a similar style for my personal projects as well.

[DyXel]

I am so used to auto-formatting that I don't even care about writing all in one line for example; Just type type type and then muscle memory to format the document, it really removes a big burden, specially if the author of the project cares about abiding to a specific format (which brings me to the point: probably the format of the codebase should also be checked on the CI).

[DyXel]

If we were to adopt a .clang-format, does anybody have one at hand we can base it on? Last time I set up one for my projects it took me a while to get it exactly how I like it (going through all the possible flags in the clang-format doc is a bit tedious). I think if we aim for one, it should minimize diff with the code that is currently on main branch, otherwise the git blame becomes more difficult to deal with.

[hsutter]

@JohelEGP You created this clang-format for Cpp2 (thanks again!). Should we add that to the repo?

[JohelEGP]

Should we add that to the repo?

I think we should first target the Cpp1 code of cppfront.