8000 Improve docs in taproot module by tcharding · Pull Request #912 · rust-bitcoin/rust-bitcoin · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Improve docs in taproot module #912

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

Merged
merged 2 commits into from
Mar 30, 2022

Conversation

tcharding
Copy link
Member

I should have done this PR a month ago, my bad. This one is kind of important IMO because we are going to have so many people looking at this part of the code soon as we release.

As has been done in other places in the codebase; improve the docs in the taproot module by doing:

  • Use full sentences (capital letters + full stops)
  • Use back ticks and links for types where appropriate
  • Fix grammar
  • Fix stale docs
  • Use third person for describing functions
  • Use 100 character line width
  • Use markdown sections (# Examples, # Returns) where appropriate
  • Separate brief heading from extended description when appropriate
  • Use /// for all functions/types (both private and public)

I also did:

  • Build the docs and check all the links
  • Read all the built docs, check for sanity and pretty-ness

Its all in one patch, I couldn't really tease it apart. I can try a bit harder if it proves too annoying to review.

@tcharding
Copy link
Member Author

CC @sanket1729 since this is taproot stuff.

Copy link
Member
@sanket1729 sanket1729 left a comment

Choose a reason for hiding this comment

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

Thank you so much for doing this.
Left one comment that needs to be changed. I need to set my editor to make use of 100 characters whenever available while commenting. I promise I will be more conscious while writing docs for my subsequent PRs.

@tcharding
Copy link
Member Author

I promise I will be more conscious while writing docs for my subsequent PRs.

I'm a firm believer that folk should work on what stimulates them, if writing clean docs is not your thing then just stick to doing you thing well :) I do these docs fixes at the end of the days or when I'm brain fried, no stress.

As has been done in other places in the codebase; improve the docs in
the `taproot` module by doing:

- Use full sentences (capital letters + full stops)
- Use back ticks and links for types where appropriate
- Fix grammar
- Fix stale docs
- Use third person for describing functions
- Use 100 character line width
- Use markdown sections (`# Examples`, `# Returns`) where appropriate
- Separate brief heading from extended description when appropriate
- Use `///` for all functions/types (both private and public)

I also did:

- Build the docs and check all the links
- Read all the built docs, check for sanity and pretty-ness
We have some text quoted directly from BIP341, this text is on the net
if folk wish to read it, we don't need it in the source code.
@tcharding
Copy link
Member Author

Force push includes:

  • the minor fixes suggested in review as part of patch 1
  • the removal of bip341 docs as a separate patch
  • I've rudely kept in my 'improved' version of the docs on with_huffman_tree even though @dr-orlovsky already fixed the stale types thing (there has to be some perks to being the monkey that does all these docs fixes :)

@tcharding
Copy link
Member Author

This PR is a candidate for either the 'RC-fix' label or the 0.28 milestone, leaving for another maintainer to add so as not to be too pushy with my own changes.

Copy link
Member
@sanket1729 sanket1729 left a comment

Choose a reason for hiding this comment

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

ACK c25eddd

@sanket1729
Copy link
Member

If we get two reviews in time, sure. I don't mind merging any changes to documentation before release.

@sanket1729 sanket1729 added the one ack PRs that have one ACK, so one more can progress them label Mar 29, 2022
Copy link
Collaborator
@dr-orlovsky dr-orlovsky left a comment

Choose a reason for hiding this comment

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

ACK c25eddd

Will wait for @apoelstra review before merge, since he had done previous review.

All my suggestions are nits, which may be addressed in the follow up PR. Not sure about the articles, but I assume that all function arg references should be prefixed with the.

Comment on lines +707 to +711
< 10000 td data-line-number="709" class="blob-num blob-num-addition">
/// - `TaprootError::InvalidControlBlockSize` if `sl` is not of size 1 + 32 + 32N for any N >= 0.
/// - `TaprootError::InvalidParity` if first byte of `sl` is not a valid output key parity.
/// - `TaprootError::InvalidTaprootLeafVersion` if first byte of `sl` is not a valid leaf version.
/// - `TaprootError::InvalidInternalKey` if internal key is invalid (first 32 bytes after the parity byte).
/// - `TaprootError::InvalidMerkleTreeDepth` if merkle tree is too deep (more than 128 levels).
Copy link
Collaborator

Choose a reason for hiding this comment

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

nit: Why not [`..`] for error types? This will allow users to jump to the description of specific error

Copy link
Member Author

Choose a reason for hiding this comment

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

Good idea.

@@ -513,15 +519,16 @@ impl TaprootBuilder {
}
}

/// Data structure used to represent node information in taproot tree.
/// Represents the node information in taproot tree.
///
Copy link
Collaborator

Choose a reason for hiding this comment

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

nit:

Suggested change
///
///
/// The data type is a helper type used in merkle tree construction allowing to build sparse merkle trees.
/// The node represents part of the tree that has information about all of its descendants. See how
/// [`TaprootBuilder`] works for more details.

Copy link
Member Author

Choose a reason for hiding this comment

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

Used with some minor tweaks.

@@ -466,7 +472,7 @@ impl TaprootBuilder {
&self.branch
}

// Helper function to insert a leaf at a depth
/// Inserts a leaf at `depth`.
Copy link
Collaborator

Choose a reason for hiding this comment

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

nit:

Suggested change
/// Inserts a leaf at `depth`.
/// Inserts a leaf at the `depth`.

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 the existing grammar is correct.

pub fn add_hidden(self, depth: usize, hash: sha256::Hash) -> Result<Self, TaprootBuilderError> {
let node = NodeInfo::new_hidden(hash);
self.insert(node, depth)
}

/// Check if the builder is a complete tree
/// Checks if the builder is a complete tree.
Copy link
Collaborator

Choose a reason for hiding this comment

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

nit

Suggested change
/// Checks if the builder is a complete tree.
/// Checks if the builder has a complete tree.

Copy link
Member

Choose a reason for hiding this comment

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

I could go either way on this one.

/// root node is 0 and it's immediate child would be at depth 1.
/// See [`TaprootBuilder::add_leaf_with_ver`] for adding a leaf with specific version
/// See [Wikipedia](https://en.wikipedia.org/wiki/Depth-first_search) for more details
/// Adds a leaf script at `depth` to the builder with default script version. Errors if the
Copy link
Collaborator

Choose a reason for hiding this comment

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

nit

Suggested change
/// Adds a leaf script at `depth` to the builder with default script version. Errors if the
/// Adds a leaf script at the `depth` to the builder with default script version. Errors if the

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'll try to explain why the original is, IMO, correct. 'depth' is not a noun in this sentence, conceptually its a location in the tree, in other words 'depth' could be replaced by 'the layer of the tree represented by usize' - hence we use 'depth' without using 'the'. Does that make sense?

@@ -412,7 +419,8 @@ impl TaprootBuilder {
Ok(TaprootBuilder{branch: vec![Some(node)]})
}

/// Just like [`TaprootBuilder::add_leaf`] but allows to specify script version
/// Adds a leaf script at `depth` to the builder with script version `ver`. Errors if the leaves
Copy link
Collaborator

Choose a reason for hiding this comment

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

nit

Suggested change
/// Adds a leaf script at `depth` to the builder with script version `ver`. Errors if the leaves
/// Adds a leaf script at the `depth` to the builder with script version `ver`. Errors if the leaves

/// Compute [`TaprootSpendInfo`] from [`NodeInfo`], and internal key.
/// This is useful when you want to manually build a taproot tree wihtout
/// using [`TaprootBuilder`].
/// Computes the [`TaprootSpendInfo`] from `internal_key` and `node`.
Copy link
Collaborator

Choose a reason for hiding this comment

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

nit

Suggested change
/// Computes the [`TaprootSpendInfo`] from `internal_key` and `node`.
/// Computes the [`TaprootSpendInfo`] from the `internal_key` and the `node`.

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 believe, in technical writing, both of these are correct. I tend to favour the more terse version. Sometimes I think we do drop too many instances of 'the' though :)

/// Create a new key spend with internal key and proided merkle root.
/// Provide [`None`] for merkle_root if there is no script path.
/// Creates a new key spend with `internal_key` and `merkle_root`. Provide [`None`] for
/// `merkle_root` if there is no script path.
Copy link
Collaborator

Choose a reason for hiding this comment

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

nit:

Suggested change
/// `merkle_root` if there is no script path.
/// the `merkle_root` if there is no script path.

Copy link
Member Author

Choose a reason for hiding this comment

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

For this one however, I like your suggestion :)

@@ -131,70 +131,73 @@ impl TapLeafHash {
}
}

/// Maximum depth of a Taproot Tree Script spend path
/// Maximum depth of a taproot tree script spend path.
Copy link
Collaborator

Choose a reason for hiding this comment

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

nit, but not sure:

Suggested change
/// Maximum depth of a taproot tree script spend path.
/// Maximum depth of a taproot tree script spending path.

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 the existing phrasing is clearer.

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 believe 'key spend' and 'script spend' are the terms being used across the eccosystem, I could be wrong.

Copy link
Member
@apoelstra apoelstra left a comment

Choose a reason for hiding this comment

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

ACK c25eddd

@dr-orlovsky dr-orlovsky merged commit 58a958e into rust-bitcoin:master Mar 30, 2022
@tcharding
Copy link
Member Author

Thanks for the review @dr-orlovsky, I'll see to your nits.

@tcharding tcharding deleted the taproot-docs branch March 30, 2022 23:41
@tcharding tcharding mentioned this pull request Mar 31, 2022
@dr-orlovsky
FB3E Copy link
Collaborator

@apoelstra @tcharding sorry for the mess with the articles in my suggestions, will not do that in a (the?) future. As a non-native speaker the whole concept of articles for me (with native Slavic language background) is ungraspable. I thought I did understood the logic of using them, but in fact not :)

@tcharding
Copy link
Member Author

the articles in my suggestions, will not do that in a (the?) future

LMAO at the '(the?)' :)

English ... what can I say, its not that easy to write well, I hope to achieve it before I die.

sanket1729 added a commit that referenced this pull request Apr 1, 2022
da731c4 Add further description to the NodeInfo struct (Tobin Harding)
492cceb Use links for error types (Tobin Harding)
3e05887 Use 'the' to improve sentence (Tobin Harding)

Pull request description:

  See to nits from review of #912

  Three minor patches to the `taproot` module docs.

  CC @dr-orlovsky

ACKs for top commit:
  dr-orlovsky:
    ACK da731c4
  sanket1729:
    ACK da731c4

Tree-SHA512: 17a27a19c88f9baa8127023b2ee30fc2259cb0058a92dc9d8ae595e9e02ccb047fefcba7548ff7900fffa7bc6853447183e80660b8756d90d055ab8aa96ae938
@apoelstra
Copy link
Member

No worries @dr-orlovsky. I am a native English speaker and I do not know any real rules for how articles are used. (If it helps I have the same difficulty in French, e.g. I was surprised that this book title uses both les and des as articles in places where the English title has no articles at all.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
one ack PRs that have one ACK, so one more can progress them
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants
0