-
Notifications
You must be signed in to change notification settings - Fork 311
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
Refactor reveal_to_target
and next_store_index
#1261
Refactor reveal_to_target
and next_store_index
#1261
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for this change. The code is clearer now. However, please revert the change to next_store_index
.
6800d62
to
a28bbb2
Compare
@danielabrozzoni I added another |
Rename `v` to `index` for better clarity, and add a comment explaining the `range`
Simplify the `reveal_to_target` algorithm by exiting prematurely if the `target_index` is already revealed. Since the `reveal_to_index` variable was different from `Some(target_index)` only if the target was already revealed, we can getrid of the variable altogether.
a28bbb2
to
5f1ee2c
Compare
5f1ee2c
to
761189a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK 761189a
// This range is filtering out the spks with a keychain different than | ||
// `keychain`. We don't use filter here as range is more optimized. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer "Range through all spks of keychain
.". However, I feel like this comment is not needed as the codebase already shows this.
Definitely not a blocker though.
Description
As a part of #1203, I found myself having to modify
reveal_to_target
, but had some troubles understanding exactly what the method was doing.This PR refactors
reveal_to_target
to be, in my opinion, a bit clearer. We now exist prematurely ifnext_reveal_index
<target_index
; this way, we don't need to keep track ofnext_reveal_index
, as it would always be equal toSome(target_index)
.As a part of trying to understand
reveal_to_target
I had to read throughnext_store_index
, I slightly improved it for clarity reasons as well.Changelog notice
Checklists
All Submissions:
cargo fmt
andcargo clippy
before committing