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

docs: standardize how we refer to methods in docstrings #1595

Closed
jku opened this issue Sep 29, 2021 · 5 comments
Closed

docs: standardize how we refer to methods in docstrings #1595

jku opened this issue Sep 29, 2021 · 5 comments
Labels
backlog Issues to address with priority for current development goals documentation Documentation of the project as well as procedural documentation low-prio

Comments

@jku
Copy link
Member

jku commented Sep 29, 2021

Current behavior:
Currently we use several different ways to refer to methods, objects and arguments in the Metadata API and ngclient docstrings. Examples:

:func:`~tuf.ngclient.updater.Updater.refresh()`    # creates a clickable link in RTD, is ugly in source
Updater.refresh()    # does not stand out from text in either RTD or source code
`Updater.refresh()`    # does not stand out from text in RTD
``Updater.refresh()``    # is rendered as "inline code" in RTD

This has been partially on purpose to see what these all look like (both in published docs and in code).

Expected behavior:

Ideally we should be consistent and follow the coding style guidelines (which somewhat reasonably argue against the sphinx links). The chosen method should be useful in the published docs and not ruin the docstring readability in source code. We'd want to apply the style in docstrings in tuf/api/ and tuf/ngclient/ (as those are used to produce the ReadTheDocs api docs).

After seeing all options I think I lean on using ``refresh()``: it creates a distinct rendering on ReadTheDocs and does not ruin the docstring readability in source code like the sphinx link format does. It does not create a clickable link but usually docstring text does not need that.

#1590 has many examples of using this format.

@jku jku added the documentation Documentation of the project as well as procedural documentation label Sep 29, 2021
@sechkova sechkova added low-prio backlog Issues to address with priority for current development goals labels Sep 29, 2021
@jku jku mentioned this issue Oct 1, 2021
4 tasks
@lukpueh
Copy link
Member

lukpueh commented Oct 20, 2021

+1 for double back-ticks. Note to myself: Add a corresponding line to https://github.com/secure-systems-lab/code-style-guidelines/blob/master/python.md#docstrings.

@jku
Copy link
Member Author

jku commented Oct 21, 2021

I didn't specify the argument names in function docstrings, which is probably the most common case... but maybe the same applies in that case: when argument names are used in the docstring, use double-backticks to get the code rendering?

@lukpueh
Copy link
Member

lukpueh commented Oct 21, 2021

I didn't specify the argument names in function docstrings...

Not sure I understand. Where did you not specify them? Above you do say "...ways to refer to methods, objects and arguments...".

At any rate, I think it's fine to use double-backticks for all of these, unless it turns out they clutter the docstrings in code or when rendered on RTD.

@jku
Copy link
Member Author

jku commented Oct 21, 2021

oops, so I did :) carry on then

@lukpueh
Copy link
Member

lukpueh commented Mar 16, 2022

@ivanayov made an effort to consolidate how we refer to methods etc. in this project (see #1856 and #1815 - thanks!). I'd say the this is now captured by the implicit code style "be consistent" and does not require an explicit recommendation in the style guide. Closing...

@lukpueh lukpueh closed this as completed Mar 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backlog Issues to address with priority for current development goals documentation Documentation of the project as well as procedural documentation low-prio
Projects
None yet
Development

No branches or pull requests

3 participants