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

Added "Provide hints to similar functions" #23788

Merged
merged 8 commits into from
Sep 25, 2017
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
24 changes: 20 additions & 4 deletions doc/src/manual/documentation.md
Original file line number Diff line number Diff line change
Expand Up @@ -81,7 +81,23 @@ As in the example above, we recommend following some simple conventions when wri
...
"""
```
5. Include any code examples in an `# Examples` section.
5. Provide hints to similar functions
Copy link
Member

Choose a reason for hiding this comment

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

Better use "related" here too. exp and log are definitely related, but I wouldn't consider them as "similar". Also missing ending period.


Sometimes there are functions of similar functionality, which are named quite different. To increase
Copy link
Member

Choose a reason for hiding this comment

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

Perhaps similar functionality -> related functionality?
Also, which are named quite different is not needed; it is useful to list related functions even if they have similar names.

discoverability please provide a short list of these similar functions in a `See also: ` section.
Copy link
Member

Choose a reason for hiding this comment

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

Perhaps: please provide a short list of these similar functions in a... -> please provide a short list of these in a ... to avoid duplication


```
See also: bar!, baz, baaz
Copy link
Member

Choose a reason for hiding this comment

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

Perhaps write this as

See also: [`bar!`](@ref), [`baz`](@ref),

etc. This will cause the identifier to be quoted and a link to its documentation will be generated in the HTML.

```
If the difference in functionality is not obvious from the name, you can provide a short description
Copy link
Member

Choose a reason for hiding this comment

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

I don't like this second part. Docstrings should be distinct and describe the function, not describe other functions. If similar functions are listed it is easy enough to look up what they do.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I did not like that part either. I proposed this list as it seems to be common practice to refer other functions with a short description in docstrings:

 Sort a multidimensional array A along the given dimension. See sort! for a description of possible keyword arguments.
  shuffle([rng=GLOBAL_RNG,] v)

  Return a randomly permuted copy of v. The optional rng argument specifies a random number generator (see Random Numbers). To
  permute v in-place, see shuffle!. To obtain randomly permuted indices, see randperm.

Perhaps the better approach is to remove these redundant descriptions and just rely on the See also:-list

Copy link
Member

Choose a reason for hiding this comment

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

The difference is that the examples you listed here refer to more documentation about the documented function -- they don’t describe other functions.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

At least the docstring to shuffle does:

 To permute v in-place, see shuffle!. To obtain randomly permuted indices, see randperm.

And i think i have seen this pattern quite often.

Should we change those docs?

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 that can be decided from case to case, and those examples are probably there for a reason. I just don't think we should explicitly recommend that style, as suggested in this PR.

in a list:

```
See also: bar! - mutating variant, see for description of keyword arguments
Copy link
Member

Choose a reason for hiding this comment

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

Are you sure this will render correctly?

baz - is an extraordinary example
baaz - even more marvellous
```
6. Include any code examples in an `# Examples` section.

Examples should, whenever possible, be written as *doctests*. A *doctest* is a fenced code block
(see [Code blocks](@ref)) starting with ````` ```jldoctest````` and contains any number of `julia>`
Expand Down Expand Up @@ -127,13 +143,13 @@ As in the example above, we recommend following some simple conventions when wri
!!! tip
Wherever possible examples should be **self-contained** and **runnable** so that readers are able
to try them out without having to include any dependencies.
6. Use backticks to identify code and equations.
7. Use backticks to identify code and equations.

Julia identifiers and code excerpts should always appear between backticks ``` ` ``` to enable
highlighting. Equations in the LaTeX syntax can be inserted between double backticks ``` `` ```.
Use Unicode characters rather than their LaTeX escape sequence, i.e. ``` ``α = 1`` ``` rather
than ``` ``\\alpha = 1`` ```.
7. Place the starting and ending `"""` characters on lines by themselves.
8. Place the starting and ending `"""` characters on lines by themselves.

That is, write:

Expand All @@ -156,7 +172,7 @@ As in the example above, we recommend following some simple conventions when wri
```

This makes it more clear where docstrings start and end.
8. Respect the line length limit used in the surrounding code.
9. Respect the line length limit used in the surrounding code.

Docstrings are edited using the same tools as code. Therefore, the same conventions should apply.
It it advised to add line breaks after 92 characters.
Expand Down