Skip to content

doc: improve formatting of STYLE_GUIDE.md #13135

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.

Sign up for GitHub

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

Closed
aqrln wants to merge 2 commits into from
Closed

doc: improve formatting of STYLE_GUIDE.md #13135

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
19efac2
doc: improve formatting of STYLE_GUIDE.md
aqrln May 20, 2017
43a021b
squash! address feedback
aqrln May 22, 2017
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
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,28 +1,29 @@
# 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"
* **OK**: "they", "their", "them", "folks", "people", "developers", "cats".
Copy link
Copy Markdown
Member

@Trott Trott May 21, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: This line and the following line probably shouldn't end with periods because they are not sentences. They are just lists. I'm OK with using a period anyway for consistency or simplicity, but I do have a slight preference for leaving the period off in this case.

Copy link
Copy Markdown
Contributor Author

@aqrln aqrln May 22, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I wasn't sure about these. They look a bit more natural without periods.

* **NOT OK**: "his", "hers", "him", "her", "guys", "dudes".
* When combining wrapping elements (parentheses and quotes), terminal
punctuation should be placed:
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
Copy link
Copy Markdown
Member

@Trott Trott May 21, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: While we're in here, can you add a comma after asterisks and backticks. (Kind of funny that this very guide recommends using a serial comma and then misses one right here!)

(**\\\_**, **\\\*** and **\\\`** instead of **\_**, **\*** and **\`**).
* References to constructor functions should use PascalCase.
* References to constructor instances should be camelCased.
Copy link
Copy Markdown
Member

@Trott Trott May 21, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: be camelCased -> use camelCase

That will be consistent with the previous line and avoid awkwardly using camelCase as a verb.

* References to methods should be used with parentheses: `socket.end()` instead
Copy link
Copy Markdown
Member

@Trott Trott May 21, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: While we're in here, add for example, after the colon.

of `socket.end`.

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