-
-
Notifications
You must be signed in to change notification settings - Fork 33.2k
doc: add "Troubleshooting" & "best practices" #12791
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
Conversation
@addaleax I commented out the "Tricks" section so there is no |
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.
Line length :)
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.
Line length.
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.
Line length.
@vsemozhetbyt fixed |
Maybe this is a nice and handy hotchpotch addition to the docs as we do not maintain our Wiki) |
Exactly |
/cc @nodejs/documentation |
I'm not sure whether or not it might be, so... is "rules of thumb" an overly "english" colloquialism? Would there be a better phrase / title? Note: I know what it means. |
Sometimes the phrase "best practices" is used in it's stead. |
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.
do these work in files?
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.
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.
it is faster on both platforms, might want to just mention it alltogether
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.
Ok. it's just that on windows the difference is amazing!
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 title seems a bit too vague. I'm not fond of junk-drawer documents (that is to say, a document you throw information in when you don't know where else to put it). So I'd prefer a specific title.
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.
(Not being cheeky but) do you have a suggestion? (Please don't say FAQ...)
Maybe "Tips & Best Practices"
P.S. usually the main problem with the "junk drawer" is finding stuff, but here we have the search function, for example if you search unknown encoding: cp65001
this will pop up.
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.
Maybe Tips and Troubleshooting for Fhqwhgads
where Fhqwhgads
is some specific activity? Like, is it "Tips for Proposing Pull Requests"? Maybe it's more broad than that, but some kind of thing that at least provides context for someone coming from Google that this isn't about troubleshooting running Node.js in production or something like that.
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.
Ok, that's good. I'll figure it out.
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.
Called it "Tips & Troubleshooting for working with the node
code"
Move the "Best practices" to a different doc
[2]: https://github.com/nodejs/node/blob/master/.eslintrc.yaml "eslintrc" | ||
[3]: https://github.com/nodejs/node/tree/master/tools/eslint-rules "Our Rules" | ||
[4]: https://github.com/nodejs/node/blob/master/doc/STYLE_GUIDE.md "MD Style" | ||
[5]: https://blog.gitprime.com/why-code-churn-matters "Why churm matters" |
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.
Churn?
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.
obv
|
||
## Tips | ||
|
||
1. If you build the code often, you should check out [`ninja`]. You may |
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.
ninja
may not need code highlight.
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 tend to ` wrap program names, but in this case, I agree it makes more sense not to
## Tips | ||
|
||
1. If you build the code often, you should check out [`ninja`]. You may | ||
find it to be faster than `make`, much much faster than `MSBuild` (Windows), and less eager to rebuild unchanged |
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.
Can we break this line at 80 chars?
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.
ccache makes more of a difference in build speed than ninja, in my experience
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.
Looks helpful to me.
I suggest adding a section explicitly saying that if you are proposing a new or changed API, that you include docs, because its much easier to review code that has docs. And maybe mention as a meta-goal for the PR "making it easy to review and accept".
I think this could be helpful as a link in the PR template, so it might be found at the time its most relevant.
@@ -0,0 +1,38 @@ | |||
# Best Practices |
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.
make heading be full title? "Best Practices for a Successful PR"
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.
ack
@@ -0,0 +1,38 @@ | |||
# Best Practices | |||
<sub>(a.k.a "Rules of thumb")</sub> |
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 don't think this adds anything.
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.
It's a search keyword trap
## Tips | ||
|
||
1. If you build the code often, you should check out [`ninja`]. You may | ||
find it to be faster than `make`, much much faster than `MSBuild` (Windows), and less eager to rebuild unchanged |
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.
ccache makes more of a difference in build speed than ninja, in my experience
|
||
[1]: http://bugs.python.org/issue1602 "python bug" | ||
[2]: http://stackoverflow.com/questions/878972/windows-cmd-encoding-change-causes-python-crash "stack overflow" | ||
|
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.
should removing trailing whitespace
Good 👍
Yea it's definatly one of the goals of the doc, I'll put it explicitly.
Maybe, but IMHO it might be too late. We need to catch them when they start conceptualizing a PR 🤔 |
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.
Can you leave a blank line under each heading? Some Markdown renderers require that.
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 agree with Sam, this should be removed.
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 seems like a sentence fragment?
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 a sentence fragment.
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’m not a fan of this entire paragraph. Some small, especially first, but meaningful contributions would fall under these categories – I would say anything that improves the codebase should be welcome; whether those changes are necessary or not is a completely different question.
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.
still a typo: self-contained
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.
typo: judgement
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.
Even I thought so. Apparently "judgment" is also valid it seems :-|
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.
huh, TIL :D feel free to disregard this then
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.
It might help to know what you mean by “pieces” – different commits, different PRs, or something else? I am not sure how specific you can get here without conflicting with “use good judgement”, but this sounds a little vague. If in doubt, remove the extra text – just saying that contributors should keep in mind that their changes will need to be reviewed in some way should help with most of the trouble that comes from large changes.
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 don’t really think most people can figure out our code style from looking at the actual ruleset – looking at surrounding code or other files should be much easier.
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 add that.
In my mind the For the harder requirements we have I'll add this "disclaimer" |
Ping @refack |
Need some follow up, but time is limited. |
More discussion on the "Rules of thumb" is in #12744
Help wanted: let's find these "tips" a better home 🏡
Fixes: #12636
[edit]
As I understand the term "rules of thumb" or "best practices", they are guidelines one should have in mind and try to adhere to, but are not necessarily hard requirements. Our requirements should be stated in the other parts of the document.
[/edit]
My suggestion for a few "rules of thumb" for code contributions.
These are obviously my personal opinion, so this PR welcomes edit and suggestions. I do think that we should put some loose guidelines in writing.
The following made me think of this, and are not critique!
Ref: #12603 - motivation
Ref: #12735 - size
Open questions:
Add a "catch all" document for tips & trick.
When adding an item, try to include the original error message or some keyword so that this doc will popup in Search.
Ref: #12786
Checklist
Affected core subsystem(s)
doc
/cc @vsemozhetbyt @gibfahn