1# Documentation style guide 2 3This style guide helps us create organized and easy-to-read documentation. It 4provides guidelines for organization, spelling, formatting, and more. 5 6These are guidelines rather than strict rules. Content is more important than 7formatting. You do not need to learn the entire style guide before contributing 8to documentation. Someone can always edit your material later to conform with 9this guide. 10 11* Documentation is in markdown files with names formatted as 12 `lowercase-with-dashes.md`. 13 * Use an underscore in the filename only if the underscore is part of the 14 topic name (e.g., `child_process`). 15 * Some files, such as top-level markdown files, are exceptions. 16* Documents should be word-wrapped at 80 characters. 17* `.editorconfig` describes the preferred formatting. 18 * A [plugin][] is available for some editors to apply these rules. 19* Check changes to documentation with `make lint-md`. 20* Use American English spelling. 21 * OK: _capitalize_, _color_ 22 * NOT OK: _capitalise_, _colour_ 23* Use [serial commas][]. 24* Avoid personal pronouns (_I_, _you_, _we_) in reference documentation. 25 * Personal pronouns are acceptable in colloquial documentation such as guides. 26 * Use gender-neutral pronouns and gender-neutral plural nouns. 27 * OK: _they_, _their_, _them_, _folks_, _people_, _developers_ 28 * NOT OK: _his_, _hers_, _him_, _her_, _guys_, _dudes_ 29* When combining wrapping elements (parentheses and quotes), place terminal 30 punctuation: 31 * Inside the wrapping element if the wrapping element contains a complete 32 clause. 33 * Outside of the wrapping element if the wrapping element contains only a 34 fragment of a clause. 35* Documents must start with a level-one heading. 36* Prefer affixing links (`[a link][]`) to inlining links 37 (`[a link](http://example.com)`). 38* When documenting APIs, update the YAML comment associated with the API as 39 appropriate. This is especially true when introducing or deprecating an API. 40* For code blocks: 41 * Use [language][]-aware fences. (<code>```js</code>) 42 * For the [info string][], use one of the following. 43 44 | Meaning | Info string | 45 | ------------- | ----------------- | 46 | Bash | `bash` | 47 | C | `c` | 48 | C++ | `cpp` | 49 | CoffeeScript | `coffee` | 50 | Diff | `diff` | 51 | HTTP | `http` | 52 | JavaScript | `js` | 53 | JSON | `json` | 54 | Markdown | `markdown` | 55 | Plaintext | `text` | 56 | Powershell | `powershell` | 57 | R | `r` | 58 | Shell Session | `console` | 59 60 If one of your language-aware fences needs an info string that is not 61 already on this list, you may use `text` until the grammar gets added to 62 [`remark-preset-lint-node`][]. 63 64 * Code need not be complete. Treat code blocks as an illustration or aid to 65 your point, not as complete running programs. If a complete running program 66 is necessary, include it as an asset in `assets/code-examples` and link to 67 it. 68* When using underscores, asterisks, and backticks, please use 69 backslash-escaping: `\_`, `\*`, and ``\` ``. 70* Constructors should use PascalCase. 71* Instances should use camelCase. 72* Denote methods with parentheses: `socket.end()` instead of `socket.end`. 73* Function arguments or object properties should use the following format: 74 * ```* `name` {type|type2} Optional description. **Default:** `value`.``` 75 <!--lint disable maximum-line-length remark-lint--> 76 * For example: <code>* `byteOffset` {integer} Index of first byte to expose. **Default:** `0`.</code> 77 <!--lint enable maximum-line-length remark-lint--> 78 * The `type` should refer to a Node.js type or a [JavaScript type][]. 79* Function returns should use the following format: 80 * <code>* Returns: {type|type2} Optional description.</code> 81 * E.g. <code>* Returns: {AsyncHook} A reference to `asyncHook`.</code> 82* Use official styling for capitalization in products and projects. 83 * OK: JavaScript, Google's V8 84 <!--lint disable prohibited-strings remark-lint--> 85 * NOT OK: Javascript, Google's v8 86* Use _Node.js_ and not _Node_, _NodeJS_, or similar variants. 87 <!-- lint enable prohibited-strings remark-lint--> 88 * When referring to the executable, _`node`_ is acceptable. 89* Be direct. 90 * OK: The return value is a string. 91 <!-- lint disable prohibited-strings remark-lint--> 92 * NOT OK: It is important to note that, in all cases, the return value will be 93 a string regardless. 94* For headings, use sentence case, not title case. 95 <!-- lint enable prohibited-strings remark-lint--> 96 * OK: _## Everybody to the limit_ 97 * NOT OK: _## Everybody To The Limit_ 98* When referring to a version of Node.js in prose, use _Node.js_ and the version 99 number. Do not prefix the version number with _v_ in prose. This is to avoid 100 confusion about whether _V8_ refers to Node.js 8.x or the V8 JavaScript 101 engine. 102 <!-- lint enable prohibited-strings remark-lint--> 103 * OK: _Node.js 14.x_, _Node.js 14.3.1_ 104 * NOT OK: _Node.js v14_ 105 106See also API documentation structure overview in [doctools README][]. 107 108For topics not covered here, refer to the [Microsoft Writing Style Guide][]. 109 110[Javascript type]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Grammar_and_types#Data_structures_and_types 111[Microsoft Writing Style Guide]: https://docs.microsoft.com/en-us/style-guide/welcome/ 112[`remark-preset-lint-node`]: https://github.com/nodejs/remark-preset-lint-node 113[doctools README]: ../../tools/doc/README.md 114[info string]: https://github.github.com/gfm/#info-string 115[language]: https://github.com/highlightjs/highlight.js/blob/master/SUPPORTED_LANGUAGES.md 116[plugin]: https://editorconfig.org/#download 117[serial commas]: https://en.wikipedia.org/wiki/Serial_comma 118