Add missing docstrings for EquivalenceLibrary#13291
Conversation
|
One or more of the following people are relevant to this code:
|
EquivalenceLibraryEquivalenceLibrary
Pull Request Test Coverage Report for Build 11709092718Warning: This coverage report may be inaccurate.This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
Details
💛 - Coveralls |
| /// | ||
| /// # Arguments: | ||
| /// * `key`: The `Key` to look for. | ||
| /// ## Arguments: |
There was a problem hiding this comment.
Is there a reason to go with H2 here?
There was a problem hiding this comment.
Nothing more than just me thinking H1 looks a bit too big here.
There was a problem hiding this comment.
Heh, understandable. Regardless, it looks like the Rust standard library uses H1 for a first level section, but it also looks like documenting arguments separately like we do in Python is actually not hip in Rust.
I would recommend that we just remove the Arguments and Returns sections on all of these methods altogether. To describe arguments that aren't self-explanatory, add a second paragraph after the summary sentence to describe the usage.
Here's what the Rust standard library uses as their convention: https://github.com/rust-lang/rfcs/blob/master/text/1574-more-api-documentation-conventions.md#appendix-a-full-conventions-text
kevinhartman
left a comment
There was a problem hiding this comment.
The Python docs look good. I left one comment recommending we use lowercase generic terms in cases where we don't want to make a code reference to a type. In general, prefer circuit or :class:`.QuantumCircuit` over QuantumCircuit. This is a fairly standard practice, e.g. Rust gives this guidance in its standard library style guide. The rationale that comes to mind is that if we know the exact type in question, we might as well use a code reference.
As for the Rust docs, I'd recommend we drop all of the Args and Returns sections, and stick with just a summary sentence, followed by an optional paragraph that describes any usage details. It's just not standard practice in Rust to list out arguments like we see in Python docs. Instead, the Rust community favors a cohesive usage description of the function as a whole when arguments aren't obvious, along with an Examples section, ideally for every method to provide usage examples. It's probably alright to skip the Examples section for most of the methods you've got in this PR, since the usage is self-explanatory and this is not yet a public interface.
- Add docs links based on @kevinhartman's comments. - Add sphinx friendly labels in docstrings.
mtreinish
left a comment
There was a problem hiding this comment.
LGTM, thanks for fixing this.
Summary
The following commits attempt to fix #13258 by adding all of the missing docstrings that were lost after #12585.
Details and comments
Add missing docstrings in the following methods:
EquivalenceLibrarystruct class.EquivalenceLibrary::get_graphmethod.EquivalenceLibrary::py_keysmethod.EquivalenceLibrary::py_node_indexmethod.EquivalenceLibrary::keysmethod.