Skip to content
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

API comment conventions #505

Merged
merged 2 commits into from
Feb 18, 2015
Merged
Changes from 1 commit
Commits
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
125 changes: 125 additions & 0 deletions text/0000-api-comment-conventions.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,125 @@
- Start Date: 2014-12-08
- RFC PR: (leave this empty)
- Rust Issue: (leave this empty)

# Summary

This is a conventions RFC, providing guidance on providing API documentation
for Rust projects, including the Rust language itself.

# Motivation

Documentation is an extremely important part of any project. It's important
that we have consistency in our documentation.

For the most part, the RFC proposes guidelines that are already followed today,
but it tries to motivate and clarify them.

# Detailed design

There are a number of indivudal guidelines:
Copy link
Contributor

Choose a reason for hiding this comment

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

s/indivudal/individual/


## Use line comments

Avoid block comments. Use line comments instead:

```rust
// Wait for the main task to return, and set the process error code
// appropriately.
```

Instead of:

```rust
/*
* Wait for the main task to return, and set the process error code
* appropriately.
*/
```

Only use inner doc comments //! to write crate and module-level documentation, nothing else.
Copy link
Member

Choose a reason for hiding this comment

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

module-level documentation

Does this only apply to module-files or also applies to mod {} blocks? It is pretty much impossible to document crates and module-files without //!, but mod {} blocks can be documented with both //! and ///.

Copy link
Member Author

Choose a reason for hiding this comment

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

This is a good question. I personally only ever use mod blocks for test code, which has no documentation. I'll add some text.


## Formatting

The first line in any doc comment should be a single-line short sentence
providing a summary of the code. This line is used as a summary description
throughout Rustdoc's output, so it's a good idea to keep it short.
Copy link

Choose a reason for hiding this comment

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

Maybe there should be a length convention to make sure rustdoc doesn't ... the first line.

Copy link
Member Author

Choose a reason for hiding this comment

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

I'm not aware of Rustdoc's behavior here, currently. Does it insert ...s? I'm not sure I've ever observed this.

Copy link
Member

Choose a reason for hiding this comment

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

The summary for a function is displayed as one line, but it uses CSS to hide any overflow with ...,

.docblock.short p {
    overflow: hidden;
    text-overflow: ellipsis;

That is, it automatically tunes how much is cut off for screen size etc, it's not rustdoc doing a hard cut off. (You can observe it by making your window thin.)

Copy link
Member Author

Choose a reason for hiding this comment

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

ahh, this is going to make it hard to have a convention then, since it's based on window size


All doc comments, including the summary line, should begin with a capital
letter and end with a period, question mark, or exclamation point. Prefer full
Copy link
Member

Choose a reason for hiding this comment

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

What about ? Does this imply that you always should write “.*[^\.?!]”[\.?!]$ and “.*[\.?!]”$ is invalid? Neither of these ‽⁇⁈⁉¿ are in the list but look like proper EOSentence symbols.

sentences to fragments.
Copy link
Member

Choose a reason for hiding this comment

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

This seems a little english-centric for generic guidelines - how about "All doc comments, ..., should be properly punctuated, full sentences."

Copy link
Member

Choose a reason for hiding this comment

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

All documentation is standardized on American English, with regards to spelling, grammar, and punctuation conventions.

Source

Copy link
Member

Choose a reason for hiding this comment

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

Yep, I think that is wrong too.


The summary line should be written in third person singular present indicative
form. Basically, this means write "Returns" instead of "Return".
Copy link

Choose a reason for hiding this comment

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

Not sure if this is "proper RFC form", but can a couple examples be included here? Not everyone knows what "third person singular present indicative form" means.

Copy link
Member Author

Choose a reason for hiding this comment

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

That's why the "Returns" instead of "Return" is here.


## Using Markdown

Within doc comments, use Markdown to format your documentation.

Use top level headings # to indicate sections within your comment. Common headings:

* Examples
* Panics
* Failure

Even if you only include one example, use the plural form: "Examples" rather
Copy link

Choose a reason for hiding this comment

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

This is really lame. If there's a single example (as is true in the vast majority of cases), the singular form should be used because that's how English works.

Tooling can use the regex Examples? instead of Examples. If the tool authors can't figure this out, we need better tool authors.

Copy link
Member

Choose a reason for hiding this comment

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

@cgaebel you're getting quite aggressive, could I ask you to tone it down a little?

Copy link
Member

Choose a reason for hiding this comment

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

+1 for singular "example"

Copy link
Member Author

Choose a reason for hiding this comment

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

An additional reason to use 'Examples' is becaue there should be more than one in most cases, and even if there is only one and they change later, the only part of the diff that changes is the addition of the example itself.

than "Example". Future tooling is easier this way.

Use graves (`) to denote a code fragment within a sentence.

Use triple graves (```) to write longer examples, like this:

This code does something cool.

```rust
let x = foo();
x.bar();
```

When appropriate, make use of Rustdoc's modifiers. Annotate triple grave blocks with
the appropriate formatting directive. While they default to Rust in Rustdoc, prefer
being explicit, so that it highlights syntax in places that do not, like GitHub.
Copy link
Member

Choose a reason for hiding this comment

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

I find this really noisey, I prefer losing syntax highlighting online to reading code polluted with "rust" all over the place.


```rust
println!("Hello, world!");
```

```ruby
puts "Hello"
```
Copy link
Member

Choose a reason for hiding this comment

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

Could you note that plain text should be marked as plain, as per #500?

Copy link
Member Author

Choose a reason for hiding this comment

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

Is it important to call out every possible annotation? I already say to annotate all of them.


Rustdoc is able to test all Rust examples embedded inside of documentation, so
it's important to mark what is not Rust so your tests don't fail.

References and citation should be linked inline. Prefer
Copy link
Member

Choose a reason for hiding this comment

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

I feel that it is somewhat important to do a proper citation for academic papers, since the link may die (or be paywalled or whatever) so having the author/title information allows people to track it down.

Copy link
Member Author

Choose a reason for hiding this comment

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

But aren't there a few different 'proper citations'? I'll admit that I'm a bit unfamilliar.

Copy link

Choose a reason for hiding this comment

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

Why is this even a rule?

Copy link
Member

Choose a reason for hiding this comment

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

@steveklabnik sure, there's various ways of doing a 'proper' citation (I don't even know what they are/how to write them by hand; I just use whatever BibTeX spits out), but that doesn't mean we should just give up on a long form entirely. :)

I guess we could chose one of the formal specifications, but it seems extremely low-priority since we don't cite things particularly often.

Copy link
Member

Choose a reason for hiding this comment

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

As long as you have the title, authors, and year, any format is OK, but having those things is standard academically and makes things easy to find.


```
[some paper](http://www.foo.edu/something.pdf)
```

to

```
some paper[1]

1: http://www.foo.edu/something.pdf
```

## English

All documentation is standardized on American English, with regards to
Copy link
Member

Choose a reason for hiding this comment

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

This doesn't seem reasonable as a generic guideline. Fine specifically for the Rust project, but not so much for the world at large. Might be better to specify a specific style guide, since precise conventions around grammar change quite a lot between them (I believe Chicago is considered relatively standard in the US, although of course Oxford is actually correct :-) )

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, this is drawing out the difference between rustc guidelines and general project ones. I've updated it to make sure this is pointing at rustc only.

spelling, grammar, and punctuation conventions. Language changes over time,
so this doesn't mean that there is always a correct answer to every grammar
question, but there is often some kind of formal consensus.

# Drawbacks

None.

# Alternatives

Not having documentation guidelines.

# Unresolved questions

None.