Drop redundant private class access specifiers #14322

This pull request drops redundant private access specifiers from class definitions where the class members are private by default.

This pull request does not rearrange class members.

NACK. IMO this is a coding-style only change. At least, you should explain more why you want to do this change or any improvement this PR do.

Too controversial for a simple change like this. Closing for now.

Well, I didn't expect to achieve the world record for fastest rejected open source contribution. :) @MarcoFalke: I get that you don't want controversial PRs. Care to elaborate what it is exactly that makes this PR too controversial? @ken2812221: in the same way that struct members are public by default and I couldn't really find an instance in the codebase where the public access specifier is used redundantly in a struct to make members that are already public by default, public again; the purpose of the pull request was to achieve the same with classes where the default access level is private.

This PR was just a trivial cleanup to get rid of a redundantly used access specifier.

utACK 0e7ec0a, easy review.

However life goes on pretty well without this change and whether this is controversial or not.

Pull requests without a rationale and clear improvement may be closed immediately.

Please provide clear motivation for your patch and explain how it improves Bitcoin Core user experience or Bitcoin Core developer experience significantly.

• Any test improvements or new tests that improve coverage are always welcome.
• All other changes should have accompanying unit tests (see src/test/) or functional tests (see test/). Contributors should note which tests cover modified code. If no tests exist for a region of modified code, new tests should accompany the change.
• Bug fixes are most welcome when they come with steps to reproduce or an explanation of the potential issue as well as reasoning for the way the bug was fixed.
• Features are welcome, but might be rejected due to design or scope issues. If a feature is based on a lot of dependencies, contributors should first consider building the system outside of Bitcoin Core, if possible.
• Refactoring changes are only accepted if they are required for a feature or bug fix or otherwise improve developer experience significantly. For example, most "code style" refactoring changes require a thorough explanation why they are useful, what downsides they have and why they significantly improve developer experience or avoid serious programming bugs. Note that code style is often a subjective matter. Unless they are explicitly mentioned to be preferred in the developer notes, stylistic code changes are usually rejected.

Bitcoin Core has a thorough review process and even the most trivial change needs to pass a lot of eyes and requires non-zero or even substantial time effort to review. There is a huge lack of active reviewers on the project, so patches often sit for a long time.

@MarcoFalke: What above all disappoints me about the way that this is closed, is that apparently the door is now closed for small contributions that may be totally insignificant or irrelevant on their own in the context of the pull request rules, but that could incrementally add up over time and turn out to be collectively very significant for the overall quality of the codebase in the long term.

The sole purpose of removing redundant code (whether it is a class, a function, a comment, redundant c-style void argument or redundant access specifiers) is to improve the quality of the codebase with small incremental steps. It has nothing to do with subjective code style or personal preference.

It has nothing to do with subjective code style or personal preference.

Arguably true, but you'd also have to make sure that an automated linter prevents introduction of new cases. If we open the door for such code style linters, there will be no upper bound on the number of them and we'd have to deal with linter-maintenance, linter-review, linter-runtime, and contributors would be forced to run all linters locally before or after submitting a patch. I don't think this burden is currently desired.