This commit enhances the readability of large numeric literals across various parts of the Bitcoin Core codebase by introducing thousands separators (’), leveraging the C++14 digit separator feature.
This readability enhancement follows the precedent set in various places within the Bitcoin Core codebase and aligns with ongoing efforts to improve code quality and developer experience: delimiters were already used in a few places, even in comments:
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
For detailed information about the code coverage, see the test coverage report.
See the guideline for information on the review process. A summary of reviews will appear here.
Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
This commit enhances the readability of large numeric literals across various consensus-related constants by introducing thousands separators ('), as per the C++14 digit separator feature. Changes are made in chainparams.cpp, amount.h, and consensus.h to include separators in the definition of constants such as nSubsidyHalvingInterval, COIN, MAX_MONEY, MAX_BLOCK_SERIALIZED_SIZE, MAX_BLOCK_WEIGHT, and MAX_BLOCK_SIGOPS_COST. This update aims to improve code clarity without affecting functionality.
- Utilize the C++14 digit separator to make large numbers more readable.
- Update nSubsidyHalvingInterval in chainparams.cpp for MAIN, TESTNET, and SIGNET chains.
- Enhance clarity of COIN and MAX_MONEY in amount.h.
- Apply readability improvements to MAX_BLOCK_SERIALIZED_SIZE, MAX_BLOCK_WEIGHT, and MAX_BLOCK_SIGOPS_COST in consensus.h.
doc/developer-notes.md).
Hey @fjahr, thanks for the quick feedback.
I have targeted these numbers, since they’re quoted to normies all the time when asking “so how do you know there isn’t an inflation bug in Bitcoin” and I can just show them:
I think it looks more reassuring if it’s organized as such. What do you think? I suspect that some lines will have to be refactored in dedicated PRs, since we won’t accidentally just touch these otherwise…
Thank you for your contribution. While this stylistic change makes sense on its own, it comes at a cost and risk for the project as a whole. The weak motivation for the change does not justify the burden that it places on the project. A burden could be any of the following:
For more information about refactoring changes and stylistic cleanup, see
Generally, if the style is not mentioned nor enforced by the developer notes, we leave it up to the original author to pick whatever fits them best personally and then leave it that way until the line is touched for other reasons.
Let us know if you have any questions.