Improve examples in docstrings

Open
#434 0 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
42/100
Issue type
Documentation
Clarity
Needs clarification
Activity status
Stale
Tech stack
python
Domain
documentation

Research direction

Start by reviewing pull request #433 and the existing docstrings it discusses. Identify examples that use sample-data or fail to follow the stated NumPy-style doctest format; done means the selected examples work, are self-contained where possible, use published PhysioNet data when appropriate, and follow a consistent style.

Written by the indexing model from the issue text.

Description

Pull request #433 brings to mind some things that could be improved in docstrings more generally. Cleaning these up might be a good starter issue.

  1. Obviously, code examples should be correct and actually work. :)

  2. Code examples should also be self-contained if possible, and avoid referring to files in sample-data (most people reading the documentation are probably not running the code directly from the git repository.) In most cases, it's better to use examples from published databases on PhysioNet.

  3. Code examples should be written in a consistent style. We generally use numpy style (https://numpydoc.readthedocs.io/en/latest/format.html) for docstrings, but we haven't been entirely consistent. In particular, numpy style requires examples to be written in "doctest" style, like this:

    """
    Examples
    --------
    >>> np.add([[1, 2], [3, 4]],
    ...        [[5, 6], [7, 8]])
    array([[ 6,  8],
           [10, 12]])
    """

This format has some nice properties (it can be tested automatically by doctest, and formatted nicely by sphinx.) On the other hand, the "..." is a little annoying when you want to copy and paste an example.

Dominant language
Jupyter Notebook
Stars
853
Forks
322
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from MIT-LCP/wfdb-python

All issues in MIT-LCP/wfdb-python

Similar issues

More Documentation issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.