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

Initial documentation for doc comment references #6080

Merged
merged 18 commits into from
Oct 10, 2024
Merged
Changes from 7 commits
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
88 changes: 88 additions & 0 deletions src/content/tools/doc-comment-references.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,88 @@
---
title: Documentation comment references
short-title: Comment references
description: Learn about doc comment references and their syntax.
---

Doc comments can contain references to various code elements. A library member
parlough marked this conversation as resolved.
Show resolved Hide resolved
or class member, etc. can be referenced by wrapping its name in square brackets
srawlins marked this conversation as resolved.
Show resolved Hide resolved
(`[...]`) in a doc comment (a comment starting with `///`). Examples:
parlough marked this conversation as resolved.
Show resolved Hide resolved

```dart
/// Returns a [String].
String f() => 'Hello';

/// Wraps [object] with [Future.value].
Future<T> g<T>(T object) => Future.value(object);
```

These doc comments contain references to the `String` class, the `object`
parameter, and the `Future.value` constructor.

## Features of references

There are several benefits to referring to a code element in a doc comment as a
doc comment reference:
srawlins marked this conversation as resolved.
Show resolved Hide resolved

### Editor features
srawlins marked this conversation as resolved.
Show resolved Hide resolved
parlough marked this conversation as resolved.
Show resolved Hide resolved

Doc comment references enable several IDE features. An element's name can be
code-completed within square brackets. When an element is renamed via an IDE
command, it can rewrite uses of that element, including references in doc
comments. When an IDE lists all "references" to an element, it can include
references in doc comments. An IDE can also provide Go-to-definition support at
the location of a doc comment reference.
srawlins marked this conversation as resolved.
Show resolved Hide resolved

### API documentation

In API documentation generated by `dart doc`, a doc comment reference is
Copy link
Member

Choose a reason for hiding this comment

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

Can you cross link dart doc to /tools/dart-doc?

Copy link
Member Author

Choose a reason for hiding this comment

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

Oops, just saw this! Done

linked, if possible, to the documentation page of the element being referenced.
If the element does not have a documentation page (for example, a function
parameter, a type variable, or a private class), then no link is created.
parlough marked this conversation as resolved.
Show resolved Hide resolved

## What can be referenced
Copy link
Member

Choose a reason for hiding this comment

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

I think this section is useful but it's a bit long and will potentially be skipped over.

Could we perhaps add another (complementary) section with a quick-reference table or list? I'm happy to help experiment with some options for doing so if you think it'd be helpful. I imagine it related each type of member with an example of its doc comment reference syntax. Many can likely be grouped together as well.

Copy link
Member Author

Choose a reason for hiding this comment

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

Great idea, I've started an attempt at this.

Copy link
Member

Choose a reason for hiding this comment

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

Thanks for exploring this! It seems a bit cramped with the table formatting, so maybe let's drop the table for now. I can revisit this with some different formats or custom styles as follow up.

Copy link
Member Author

Choose a reason for hiding this comment

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

SG. I'm sure there's a good solution in here. Maybe just experiment with different table layouts.


Most library members can be referenced in a doc comment, including classes,
constants, enums, named extensions, extension types, functions, mixins, and
type aliases. This includes all in-scope library members, either declared
locally, or imported. Library members which are imported with an import prefix
srawlins marked this conversation as resolved.
Show resolved Hide resolved
can be referenced with the prefix. Examples:
srawlins marked this conversation as resolved.
Show resolved Hide resolved

```dart
import 'dart:math' as math;

/// [List] is in scope.
/// So is [math.max].
int x = 7;
```

Most members of a class, an enum, an extension, an extension type, and a mixin
can also be referenced. A reference to a member that is not in scope must be
qualified with its container's name. For example the `wait` static method on
Copy link
Member

Choose a reason for hiding this comment

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

We don't use the word "qualified" a lot in the docs. I think readers will mostly understand from the following context, but would it be helpful to clarify it means prefixed in this case?

Suggested change
qualified with its container's name. For example the `wait` static method on
qualified (prefixed) with its container's name. For example, the `wait` static method on

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 like it, thanks!

the `Future` class can be referenced in a doc comment with `[Future.wait]`.
This is true for instance members as well; the `add` method and the `length`
property on the `List` class can be referenced with `[List.add]` and
`[List.length]`. In-scope members like these can even be referenced without the
qualifying container name:
srawlins marked this conversation as resolved.
Show resolved Hide resolved

```dart
abstract class MyList<E> implements List<E> {
/// Refer to [add] and [contains], which is declared on [Iterable].
void myMethod() {}
}
```

Parameters of a function and parameters of a function type can be referenced in
a doc comment only when they are in scope. They can therefore only be
referenced within a doc comment on such a parameter's function or on a type
alias for such a paramter's enclosing function type.
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
alias for such a paramter's enclosing function type.
alias for such a parameter's enclosing function type.

Copy link
Member Author

Choose a reason for hiding this comment

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

Done


Type parameters can be referenced in a doc comment only when they are in scope.
Therefore a type parameter of a method, top-level function, or type alias can
only be referenced within a doc comment on that element, and a type parameter
of a class, enum, extension, extension type, and mixin can only be referenced
within a doc comment on that element or on one of its members.

The doc comment for a type alias which aliases a class, enum, extension type,
srawlins marked this conversation as resolved.
Show resolved Hide resolved
or mixin cannot reference any of the aliased type's members, if it has any, as
srawlins marked this conversation as resolved.
Show resolved Hide resolved
if they were in scope.
Copy link
Member

Choose a reason for hiding this comment

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

I got a bit lost reading this sentence, perhaps due to the two separated "if" clauses. I think it might be better to just drop both of them, as the meaning seems the same. If it helps or you prefer, you could add a "bad" code snippet.

If you mark a code block as follows, it will be stylized and noted as "bad".

```dart tag=bad
// Some bad code
```