|
1 | 1 | # Style Guide
|
2 | 2 |
|
3 | 3 | * Documents are written in markdown files.
|
4 |
| -* Those files should be written in **`lowercase-with-dashes.md`.** |
| 4 | +* Those files should be written in **`lowercase-with-dashes.md`**. |
5 | 5 | * Underscores in filenames are allowed only when they are present in the
|
6 |
| - topic the document will describe (e.g., `child_process`.) |
| 6 | + topic the document will describe (e.g., `child_process`). |
7 | 7 | * Filenames should be **lowercase**.
|
8 | 8 | * Some files, such as top-level markdown files, are exceptions.
|
9 | 9 | * Older files may use the `.markdown` extension. These may be ported to `.md`
|
10 | 10 | at will. **Prefer `.md` for all new documents.**
|
11 | 11 | * Documents should be word-wrapped at 80 characters.
|
12 | 12 | * The formatting described in `.editorconfig` is preferred.
|
13 |
| - * A [plugin][] is available for some editors to automatically apply these rules. |
| 13 | + * A [plugin][] is available for some editors to automatically apply these |
| 14 | + rules. |
14 | 15 | * Mechanical issues, like spelling and grammar, should be identified by tools,
|
15 | 16 | insofar as is possible. If not caught by a tool, they should be pointed out by
|
16 | 17 | human reviewers.
|
17 | 18 | * American English spelling is preferred. "Capitalize" vs. "Capitalise",
|
18 | 19 | "color" vs. "colour", etc.
|
19 | 20 | * Though controversial, the [Oxford comma][] is preferred for clarity's sake.
|
20 | 21 | * Generally avoid personal pronouns in reference documentation ("I", "you",
|
21 |
| - "we".) |
| 22 | + "we"). |
22 | 23 | * Pronouns are acceptable in more colloquial documentation, like guides.
|
23 | 24 | * Use **gender-neutral pronouns** and **mass nouns**. Non-comprehensive
|
24 | 25 | examples:
|
25 | 26 | * **OK**: "they", "their", "them", "folks", "people", "developers", "cats"
|
26 |
| - * **NOT OK**: "his", "hers", "him", "her", "guys", "dudes". |
| 27 | + * **NOT OK**: "his", "hers", "him", "her", "guys", "dudes" |
27 | 28 | * When combining wrapping elements (parentheses and quotes), terminal
|
28 | 29 | punctuation should be placed:
|
29 | 30 | * Inside the wrapping element if the wrapping element contains a complete
|
|
54 | 55 | your point, not as complete running programs. If a complete running program
|
55 | 56 | is necessary, include it as an asset in `assets/code-examples` and link to
|
56 | 57 | it.
|
57 |
| -* When using underscores, asterisks and backticks please use proper escaping (**\\\_**, **\\\*** and **\\\`** instead of **\_**, **\*** and **\`**) |
58 |
| -* References to constructor functions should use PascalCase |
59 |
| -* References to constructor instances should be camelCased |
60 |
| -* References to methods should be used with parentheses: `socket.end()` instead of `socket.end` |
| 58 | +* When using underscores, asterisks, and backticks, please use proper escaping |
| 59 | + (**\\\_**, **\\\*** and **\\\`** instead of **\_**, **\*** and **\`**). |
| 60 | +* References to constructor functions should use PascalCase. |
| 61 | +* References to constructor instances should use camelCase. |
| 62 | +* References to methods should be used with parentheses: for example, |
| 63 | + `socket.end()` instead of `socket.end`. |
61 | 64 |
|
62 | 65 | [plugin]: http://editorconfig.org/#download
|
63 | 66 | [Oxford comma]: https://en.wikipedia.org/wiki/Serial_comma
|
0 commit comments