One of the big Taylorist mistakes of our industry IMO. It is OK to have churn, and it's certainly better to have a little too much than too few.
If you want to make those:
* make it in separate bunch of commits * make sure team uses tooling that will not allow new style problems to happen, like mandating certain formatter with certain settings before each commit. Most editors have hooks to do it automatically, and if they don't, Git have them too
It also makes git blame less useful althought it now have options to ignore moved code or whitespace changes so it isn't as much of a deal now.
However, plenty of useful changes also qualify as churn, for instance:
* renaming stuff
* extracting a function to split a block that may have been fine for the author, but that you found hard to read. And yes, sometimes, reviews don't catch all those.
* Add a comment to provide context to an algorithm after you talked with business
All of these things (and others) are pretty valuable, and the cumulative effect of reducing friction against these changes add up to much better codebases, with less places where no one wants to work because of abandonment. This kind of light touches should take a couple minutes while reading your codebase, not half-a-day because you need to fill a PR and wait for someone to be available.
1. Continuous deployment means your mainline is sacred and always in a releasable state.
2. Unit tests and automated verifications only tell part of the story
3. Churn should be avoided (e.g. fixing code style issues); if fixes are made before it enters the mainline, it is avoided.
4. Code reviews should be asynchronous, because pulling someone out of their flow to switch to doing a code review is rude and unproductive.