Consistent formatting & other minor fixes

[knatten]

Thanks for fixing this! I had an idea for how to auto format most of the code, without messing up manual formatting of questions like https://cppquiz.org/quiz/question/127. We could add an extra field auto_format to the Question model, which if toggled, causes the code to run through clang-format on save. This should be False by default to avoid to messing up manual formatting in the contribution form, but then mods could turn it on during review for most questions.

clang-format turns out to be installable through pip, which is very handy. We also need to create a .clang-format file.

What do you think? Should we turn the above into an issue? Or do you have any other ideas for how to solve this?

[tocic]

I'm definitely for the ability to autoformat the code consistently (i.e. the presence of .clang-format and a fixed version of clang-format). Then the question is whether we want to provide this ability to submitters or only to mods/admins. If the former, I'd add a button to do just that (pressing it is optional and it's possible to continue manual formatting after the press). If the latter, maybe it's already good enough to just run clang-format by hand and click on the existing "VIEW ON SITE" or "preview" buttons to see how it looks (but the new button would be handy anyway). So my main point is that the user who does the formatting should be able to see the end result before submitting/saving, not after.

[knatten]

I'm definitely for the ability to autoformat the code consistently (i.e. the presence of .clang-format and a fixed version of clang-format). Then the question is whether we want to provide this ability to submitters or only to mods/admins. If the former, I'd add a button to do just that (pressing it is optional and it's possible to continue manual formatting after the press). If the latter, maybe it's already good enough to just run clang-format by hand and click on the existing "VIEW ON SITE" or "preview" buttons to see how it looks (but the new button would be handy anyway). So my main point is that the user who does the formatting should be able to see the end result before submitting/saving, not after.

Yeah that would be best. I've added https://github.com/knatten/cppquiz/issues/356, then we can get back to this later.

[tocic]

OK, let's merge the last 2 questions and I'll rebase this PR and write a comment.

[knatten]

OK, let's merge the last 2 questions and I'll rebase this PR and write a comment.

Good plan!

[tocic]

\<changes> — \<reason> — \<automatable>:

1. use `` instead of ` for code blocks (even inside quotes) — easier to read/write, code highlighting — greppable
2. no using namespace std; — more vertical space — clang-tidy/greppable
3. no EOL at EOF — consistency — clang-format can consistently do the opposite
4. 2 or 4 spaces for code indentation — consistency, more horizontal space — clang-format
5. (...) for omitting, [some text] for our remarks inside references — consistency — not
6. */** instead of _/__ — consistency, to support _ in refs — not
7. https instead of http — security — greppable
8. strip whitespace — easier to read — git
9. remove/replace non-printable chars — looks like they are present in the original standard draft so we can ignore them in the future — greppable
10. add missing punctuation — consistency, easier to read — partially greppable
11. use > instead of "" for refs — easier to read, better highlighting — not
12. empty line before a quote — consistency, easier to read in long explanations — greppable
13. > instead of just > — consistency, easier to read — greppable
14. use > (right angle bracket + newline) for linebreaks in quotes — vanilla markdown syntax, idk why it renders correctly without them — not
15. try to preserve the original formatting in quotes — hightlighting, easier to match — not
16. always add a hint — if there's "No hint", the user loses his score for nothing — greppable
17. refer to ¶note-X and ¶general-example-Y directly where appropriate — no need to write [*Note X*: and — *end example*] — not