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

refactor: removes redundant for loop #2955

Closed
wants to merge 1 commit into from

Conversation

fahimahmedx
Copy link
Contributor

@fahimahmedx fahimahmedx commented Dec 20, 2023

Overview

There are two for loops that iterate over the same values. This small PR combines them into one.

Checklist

  • New and updated code has appropriate documentation
  • New and updated code has new and/or updated testing
  • Required CI checks are passing
  • Visual proof for any user facing features like CLI or documentation updates
  • Linked issues closed with keywords

Copy link
Contributor

coderabbitai bot commented Dec 20, 2023

Walkthrough

Walkthrough

The update involves the removal of a loop from the gov_handler.go file, which previously iterated over parameter changes. This modification affects how parameter change proposals are processed, potentially simplifying the logic or altering the functionality in a significant way.

Changes

File Path Change Summary
.../paramfilter/gov_handler.go Removed a loop that iterated over p.Changes, along with its conditional block, impacting the handling of parameter change proposals.

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on X ?


Tips

Chat with CodeRabbit Bot (@coderabbitai)

  • You can reply to a review comment made by CodeRabbit.
  • You can tag CodeRabbit on specific lines of code or files in the PR by tagging @coderabbitai in a comment.
  • You can tag @coderabbitai in a PR comment and ask one-off questions about the PR and the codebase. Use quoted replies to pass the context for follow-up questions.

CodeRabbit Commands (invoked as PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger a review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • The JSON schema for the configuration file is available here.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/coderabbit-overrides.v2.json

@celestia-bot celestia-bot requested a review from a team December 20, 2023 05:04
Comment on lines 60 to 62
ss, ok := pk.GetSubspace(c.Subspace)
if !ok {
return sdkerrors.Wrap(proposal.ErrUnknownSubspace, c.Subspace)
Copy link
Contributor

Choose a reason for hiding this comment

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

To ensure that the performance improvement is significant and does not introduce any regressions, consider adding benchmarks or performance tests if not already present.

Copy link
Contributor

@cmwaters cmwaters left a comment

Choose a reason for hiding this comment

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

I think we need the two for loops here because the rule is that if one parameter change is blocked then all other changes are void.

That being said it might be fine because if we perform an Update and later realise that one of the parameters is blocked, it should simply fail the transaction and not apply it to state.

Generally there are going to only be a few parameters that get changed in a single proposal so I don't think the optimisation provides much gains

@rootulp
Copy link
Collaborator

rootulp commented Dec 20, 2023

That being said it might be fine because if we perform an Update and later realise that one of the parameters is blocked, it should simply fail the transaction and not apply it to state.

I think this test covers that scenario but I agree, the optimization doesn't seem strictly necessary and IMO the code is a bit more readable with two for loops.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants