Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Refactor block_cemented_callback for readability #4306

Merged

Conversation

gr0vity-dev
Copy link
Contributor

  • Modularized the block confirmation logic into separate functions.
  • Separated active and inactive block confirmation processes.
  • Simplified the main block_cemented_callback() function for easier understanding.
  • Reduced nested conditionals by early returning and using helper methods.
  • Improved code readability and maintainability.

Marked as draft PR to discuss if such a breakup into smaller methods is desirable

- Modularized the block confirmation logic into separate functions.
- Separated active and inactive block confirmation processes.
- Simplified the main block_cemented_callback() function for easier understanding.
- Reduced nested conditionals by early returning and using helper methods.
- Improved code readability and maintainability.
Copy link
Contributor

@clemahieu clemahieu left a comment

Choose a reason for hiding this comment

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

I added a couple style comments but since this is just moving code let's ignore those for now and do the direct code copying.

nano/node/active_transactions.cpp Outdated Show resolved Hide resolved
nano/node/active_transactions.cpp Outdated Show resolved Hide resolved
nano/node/active_transactions.cpp Outdated Show resolved Hide resolved
nano/node/active_transactions.cpp Outdated Show resolved Hide resolved
nano/node/active_transactions.cpp Outdated Show resolved Hide resolved
}
}

void nano::active_transactions::activate_scheduler_for_account_and_destination (const nano::account & account, std::shared_ptr<nano::block> const & block, nano::store::read_transaction const & transaction)
Copy link
Contributor

Choose a reason for hiding this comment

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

This name is a bit long. Maybe "activate_dependents".

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I agree that it's too long. Since it activates the next blocks, what about "activate_successors" ?

nano/node/active_transactions.cpp Outdated Show resolved Hide resolved
- auto transaction
- switch statement
- rename to `election_status`
- remove redundant {}
- use initialization syntax amount{ 0 }
- rename to `handle_confirmation`
- rename to `activate_successors`
@gr0vity-dev
Copy link
Contributor Author

Thanks for the feedback. I applied all your suggestions.
One thing I noticed is that we mostly use {variable}_a in the method definition, to indicate it's an argument ?
Should I keep that convention when splitting into smaller methods ?

@gr0vity-dev gr0vity-dev marked this pull request as ready for review October 4, 2023 06:51
@clemahieu
Copy link
Contributor

Thanks for the feedback. I applied all your suggestions. One thing I noticed is that we mostly use {variable}_a in the method definition, to indicate it's an argument ? Should I keep that convention when splitting into smaller methods ?

I've been moving away from that convention. Since argument names are looked at by the users I think it's better to keep those clean.

I still use _m (class member) and _l (local variable) when there are name shadowing issues because those aren't often looked at by end users.

process_inactive_confirmation (transaction, block_a);
break;

default:
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think we should use a default clause here but that's the existing functionality so I guess we can keep it.

@clemahieu clemahieu merged commit 3b22533 into nanocurrency:develop Oct 4, 2023
32 of 34 checks passed
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants