Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add guidelines for formatting questions and explanations #357

Open
knatten opened this issue Sep 18, 2024 · 0 comments
Open

Add guidelines for formatting questions and explanations #357

knatten opened this issue Sep 18, 2024 · 0 comments

Comments

@knatten
Copy link
Owner

knatten commented Sep 18, 2024

Suggestions from @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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant