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

doc: improve formatting of STYLE_GUIDE.md #13135

Closed
wants to merge 2 commits into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 12 additions & 9 deletions doc/STYLE_GUIDE.md
Original file line number Diff line number Diff line change
@@ -1,29 +1,30 @@
# Style Guide

* Documents are written in markdown files.
* Those files should be written in **`lowercase-with-dashes.md`.**
* Those files should be written in **`lowercase-with-dashes.md`**.
* Underscores in filenames are allowed only when they are present in the
topic the document will describe (e.g., `child_process`.)
topic the document will describe (e.g., `child_process`).
* Filenames should be **lowercase**.
* Some files, such as top-level markdown files, are exceptions.
* Older files may use the `.markdown` extension. These may be ported to `.md`
at will. **Prefer `.md` for all new documents.**
* Documents should be word-wrapped at 80 characters.
* The formatting described in `.editorconfig` is preferred.
* A [plugin][] is available for some editors to automatically apply these rules.
* A [plugin][] is available for some editors to automatically apply these
rules.
* Mechanical issues, like spelling and grammar, should be identified by tools,
insofar as is possible. If not caught by a tool, they should be pointed out by
human reviewers.
* American English spelling is preferred. "Capitalize" vs. "Capitalise",
"color" vs. "colour", etc.
* Though controversial, the [Oxford comma][] is preferred for clarity's sake.
* Generally avoid personal pronouns in reference documentation ("I", "you",
"we".)
"we").
* Pronouns are acceptable in more colloquial documentation, like guides.
* Use **gender-neutral pronouns** and **mass nouns**. Non-comprehensive
examples:
* **OK**: "they", "their", "them", "folks", "people", "developers", "cats"
* **NOT OK**: "his", "hers", "him", "her", "guys", "dudes".
* **NOT OK**: "his", "hers", "him", "her", "guys", "dudes"
* When combining wrapping elements (parentheses and quotes), terminal
punctuation should be placed:
* Inside the wrapping element if the wrapping element contains a complete
Expand Down Expand Up @@ -54,10 +55,12 @@
your point, not as complete running programs. If a complete running program
is necessary, include it as an asset in `assets/code-examples` and link to
it.
* When using underscores, asterisks and backticks please use proper escaping (**\\\_**, **\\\*** and **\\\`** instead of **\_**, **\*** and **\`**)
* References to constructor functions should use PascalCase
* References to constructor instances should be camelCased
* References to methods should be used with parentheses: `socket.end()` instead of `socket.end`
* When using underscores, asterisks, and backticks, please use proper escaping
(**\\\_**, **\\\*** and **\\\`** instead of **\_**, **\*** and **\`**).
* References to constructor functions should use PascalCase.
* References to constructor instances should use camelCase.
* References to methods should be used with parentheses: for example,
`socket.end()` instead of `socket.end`.

[plugin]: http://editorconfig.org/#download
[Oxford comma]: https://en.wikipedia.org/wiki/Serial_comma