[wallet.cpp] replace NULL with nullptr #14203

came with cebefba0855cee7fbcb9474b34e6779369e8e9ce

a linter would be nice to detect those

utACK 2d8fe248cbe0a6a8cee013f828cdb446bb3cf05e

utACK 2d8fe24.

<!--e57a25ab6845829454e8d69fc972939a-->Note to reviewers: This pull request conflicts with the following ones:

• #10973 (Refactor: separate wallet from node by ryanofsky)

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.

utACK 2d8fe248cbe0a6a8cee013f828cdb446bb3cf05e

This PR already has 3 ACKs, but in general I don't think we should encourage PRs that do code style refactors for no clear benefit. See https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#refactoring :

Trivial pull requests or pull requests that refactor the code with no clear benefits may be immediately closed by the maintainers to reduce unnecessary workload on reviewing.

@jnewbery Using nullptr instead of NULL consistently will avoid a certain class of bugs.

nullptr cannot be confused with an int. nullptr also has a well-specified (very restrictive) type, and thus works in more scenarios where type deduction might do the wrong thing on NULL or 0.

Using nullptr instead of NULL consistently will avoid a certain class of bugs.

I can't see how changing NULL to nullptr avoids a bug in this instance.

Yes, in general, nullptr should be preferred to NULL (as is prescribed in the developer notes), but having PRs that change individual cases of NULL to nullptr are not a good use of reviewer and maintainer time. They increase PR traffic and code churn for no discernible benefit. Contributor, reviewer and maintainer time would be better employed in fixing known bugs or adding features. There are currently 552 issues open against this repo: https://github.com/bitcoin/bitcoin/issues. We should focus on tackling those rather than opening code style refactor PRs.

Sorry, there is too much noise and discussion for a simple stylistic change like this. These stylistic changes are better catched during review and too late to fix up after review due to the massive overhead involved in pull requests.

@HashUnlimited - thanks for offering your contribution! Sorry that this one didn't get in.

If you're still interested in contributing there are a bunch of 'Good first issues' here: https://github.com/bitcoin/bitcoin/labels/good%20first%20issue . It'd be great if you wanted to take one of those.