-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Add rustdoc doc #66267
Add rustdoc doc #66267
Conversation
0543358
to
8e41089
Compare
This chapter intends to explain how to not only write documentation but also on | ||
how to write **good** ones. But something to keep in mind when writing | ||
documentation: you write as much for others as for you so it's important to be | ||
clear! The more the better. If an item is public, then it should be documented. |
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.
Multiline suggestions don't work, but I'd suggest:
This chapter covers not only how to write documentation but specifically
how to write **good** documentation. Something to keep in mind when
writing documentation is that your audience is not just yourself but others
who simply don't have the context you do. It is important to be as clear
as you can, and as complete as possible. As a rule of thumb, the more
documentation you write for your crate, the better. If an item is public
then it should be documented.
|
||
## Basic structure | ||
|
||
If possible, each item's documentation should try to follow this structure: |
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.
If possible, each item's documentation should try to follow this structure: | |
It is recommended that each item's documentation follows this basic structure: |
Pretty simple but important to follow. The code example is really important: | ||
it might help your users to have a better understanding of what an item is | ||
used for and/or how to use it. |
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 think it's risky to describe documentation as 'simple' to produce. Perhaps:
This basic structure should be straightforward to follow when writing your
documentation and, while you might think that a code example is trivial,
the examples are really important because they can help your users to
understand what an item is, how it is used, and for what purpose it exists.
used for and/or how to use it. | ||
|
||
Let's see an example coming from the [standard library] by taking a look at the | ||
[env::args] function: |
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.
[env::args] function: | |
[`std::env::args()`][env::args] function: |
The documentation is using the [commonmark markdown specification]. You might be | ||
interested into taking a look at their website to see what's possible to do! |
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.
Here I think it's important to make it clear that rustdoc
uses commonmark, and if possible some of the text about taking a look should try and link to the requisite part of the commonmark site. I also dislike the !
😄
|
||
Here is the list of the lints provided by `rustdoc`: | ||
|
||
## intra_doc_link_resolution_failure |
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 we label this one "nightly only" ?
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.
Also should we say this is warn-by-default?
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.
Yes for both!
8e41089
to
a362924
Compare
Updated. |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
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 looks great! ❤️
This lint is **allowed by default**. It detects documentation tests when they | ||
are on a private item. For example: |
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 this could have a brief comment explaining why someone might want to use it? From what I understand, private doc tests are tested, it's just that they do not have access to private items, so its usefulness is limited, is that correct?
My initial reading, I was thinking maybe private doc tests were not tested or something.
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 where we should give this explanation from my point of view.
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.
Looking pretty solid
writing documentation is that your audience is not just yourself but others | ||
who simply don't have the context you do. It is important to be as clear | ||
as you can, and as complete as possible. As a rule of thumb, the more | ||
documentation you write for your crate, the better. If an item is public |
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.
documentation you write for your crate, the better. If an item is public | |
documentation you write for your crate the better. If an item is public |
Looks like I left a spurious comma in before
how to write **good** documentation. Something to keep in mind when | ||
writing documentation is that your audience is not just yourself but others | ||
who simply don't have the context you do. It is important to be as clear | ||
as you can, and as complete as possible. As a rule of thumb, the 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.
as you can, and as complete as possible. As a rule of thumb, the more | |
as you can, and as complete as possible. As a rule of thumb: the more |
a362924
to
528b059
Compare
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 happy with this as a first step on the way to good "how to write docs" section. 👍
Then let's get it in! @bors: r=kinnison rollup |
📌 Commit 528b059 has been approved by |
…innison Add rustdoc doc r? @kinnison
Rollup of 11 pull requests Successful merges: - #65965 (Clean up librustc_typeck error_codes file) - #66230 (remove vestigial comments referring to defunct numeric trait hierarchy) - #66241 (bump openssl version) - #66257 (Drop long-section-names linker workaround for windows-gnu) - #66263 (make the error message more readable) - #66267 (Add rustdoc doc) - #66276 (Move lock into CodeStats) - #66278 (Fix error message about exported symbols from proc-macro crates) - #66280 (Fix HashSet::union performance) - #66299 (support issue = "none" in unstable attributes ) - #66309 (Tiny cleanup to size assertions) Failed merges: r? @ghost
…vel-doc, r=Dylan-DPC Add lint when no doc is present at the crate-level Follow-up of rust-lang#66267. r? @kinnison
…vel-doc, r=Dylan-DPC Add lint when no doc is present at the crate-level Follow-up of rust-lang#66267. r? @kinnison
…l-doc, r=Dylan-DPC Add lint when no doc is present at the crate-level Follow-up of rust-lang#66267. r? @kinnison
r? @kinnison