mirror of
https://github.com/nodejs/node.git
synced 2024-11-29 23:16:30 +01:00
882b61a7ee
Fix broken links found by the checker, and exclude test/fixtures as it contains invalid links. Also exclude doc/changelogs because they're huge files which take very long to parse, and (IIRC) are auto-generated anyway. (Oh and also a nit at the README next to my link) PR-URL: https://github.com/nodejs/node/pull/32586 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
3.6 KiB
3.6 KiB
Style Guide
- Documentation is in markdown files with names formatted as
lowercase-with-dashes.md
.- Use an underscore in the filename only if the underscore is part of the
topic name (e.g.,
child_process
). - Some files, such as top-level markdown files, are exceptions.
- Use an underscore in the filename only if the underscore is part of the
topic name (e.g.,
- Documents should be word-wrapped at 80 characters.
.editorconfig
describes the preferred formatting.- A plugin is available for some editors to apply these rules.
- Check changes to documentation with
make lint-md
. - Use American English spelling.
- OK: capitalize, color
- NOT OK: capitalise, colour
- Use serial commas.
- Avoid personal pronouns (I, you, we) in reference documentation.
- Personal pronouns are acceptable in colloquial documentation such as guides.
- Use gender-neutral pronouns and gender-neutral plural nouns.
- OK: they, their, them, folks, people, developers
- NOT OK: his, hers, him, her, guys, dudes
- When combining wrapping elements (parentheses and quotes), place terminal
punctuation:
- Inside the wrapping element if the wrapping element contains a complete clause.
- Outside of the wrapping element if the wrapping element contains only a fragment of a clause.
- Documents must start with a level-one heading.
- Prefer affixing links (
[a link][]
) to inlining links ([a link](http://example.com)
). - When documenting APIs, update the YAML comment associated with the API as appropriate. This is especially true when introducing or deprecating an API.
- For code blocks:
- Use language aware fences. ("```js")
- Code need not be complete. Treat code blocks as an illustration or aid to
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
backslash-escaping:
\_
,\*
, and\`
. - Constructors should use PascalCase.
- Instances should use camelCase.
- Denote methods with parentheses:
socket.end()
instead ofsocket.end
. - Function arguments or object properties should use the following format:
* `name` {type|type2} Optional description. **Default:** `value`.
- For example:
*
byteOffset
{integer} Index of first byte to expose. Default:0
.
- The
type
should refer to a Node.js type or a JavaScript type.
- Function returns should use the following format:
* Returns: {type|type2} Optional description.
- E.g.
* Returns: {AsyncHook} A reference to
asyncHook
.
- Use official styling for capitalization in products and projects.
- OK: JavaScript, Google's V8
- NOT OK: Javascript, Google's v8
- Use Node.js and not Node, NodeJS, or similar variants.
- When referring to the executable,
node
is acceptable.
- When referring to the executable,
- Be direct.
- OK: The return value is a string.
- NOT OK: It is important to note that, in all cases, the return value will be a string regardless.
See also API documentation structure overview in doctools README.