-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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, tools: formalize, unify and codify default values #19737
Conversation
cc @nodejs/documentation |
doc/STYLE_GUIDE.md
Outdated
@@ -16,8 +16,8 @@ | |||
* Avoid personal pronouns in reference documentation ("I", "you", "we"). | |||
* 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" | |||
* OK: "they", "their", "them", "folks", "people", "developers". |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not a sentence so I don't think a .
at the end makes sense here. Same for the line below.
doc/STYLE_GUIDE.md
Outdated
@@ -43,7 +43,7 @@ | |||
* For illustrations, prefer SVG to other assets. When SVG is not feasible, | |||
please keep a close eye on the filesize of the asset you're introducing. | |||
* For code blocks: | |||
* Use language aware fences. ("```js") | |||
* Use language aware fences. ("```js"). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove the period after fences
if we're putting one after the parenthetical.
doc/STYLE_GUIDE.md
Outdated
* Function returns should use the following format: | ||
* <code>* Returns: {type|type2} Optional description.</code> | ||
* E.g. <code>* Returns: {AsyncHook} A reference to `asyncHook`.</code> | ||
* Use official styling for capitalization in products and projects. | ||
* OK: JavaScript, Google's V8 | ||
* NOT OK: Javascript, Google's v8 | ||
* OK: JavaScript, Google's V8. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, this is a list and not a sentence, so I don't think it warrants punctuation at the end. Same for the line below.
doc/api/assert.md
Outdated
@@ -469,7 +469,7 @@ parameter is an instance of an [`Error`][] then it will be thrown instead of the | |||
<!-- YAML | |||
added: v0.1.21 | |||
--> | |||
* `message` {any} **Default:** `'Failed'` | |||
* `message` {any} **Default:** `'Failed'`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll stop after this one, but basically I don't think that we should put periods after values that aren't otherwise part of a sentence or even a phrase.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will undo,
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've removed the periods if:
- default value statement is not a sentence;
- default value statement is not after a sentence (is not after a period).
Still not a fan of all the added periods, but at least they're consistent, so non-blocking objection. But if you want my opinion on where periods should and shouldn't go, let me know. :-D |
As a not native speaker, I definitely need to understand more) So if you add some notes, I will edit accordingly. |
I'm having a lot of trouble finding examples in documentation (of other languages) or in style guides to support the approach I would suggest. And what I am finding basically amounts to "There are no definite rules other than to be consistent." So maybe best to just go with the approach you have here. (I would expect that |
Thinking more on it: "Always add a period" does have the advantage that it requires no debate/decision to be made. It's simple. I think I may be coming around to your approach. :-D |
Human language is a live tricky thing) |
What I was thinking about the second edition:
is hardly a sentence or phrase, more likely a tag, a formal construction.
is a story, a narrative, a natural flow, and its momentum makes even partial phrases be more sentence-like, as a sentence with an ellipsis. |
PR-URL: #19737 Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Landed in 237cbe1 |
Should this be backported to |
Backport to v9: #19793 |
Should this be backported to |
Backport to v8: #22388 |
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesStatus Quo
The format of default values is defined in STYLE_GUIDE.md. But the current state of sources is not unified: many default values are stated in informal ways or with tiny deviations.
tools/doc/json.js
has an obsolete RegExp to detect the default values in parameter lists. Because of this, only onedefault
field is added to JSON docs, and even this is detected wrongly: this source produces this item:insstead of:
{ "textRaw": "`undefined` (default): use [`http.globalAgent`][] for this host and port. ", "name": "undefined", + "desc": "(default): use [`http.globalAgent`][] for this host and port." }
Fixing strategy
The first commit formalizes and unifies doc sources: informal definitions are replaced by formal ones, deviating nits in the formal definitions are unified (definitions are moved to the end, backticks and periods are added, duplicate info is removed etc.)
The second commit codifies default values format: periods are added to STYLE_GUIDE.md and RegExp in
tools/doc/json.js
is replaced by the actual one.Results
JSON example of old and new state in diff: