And if you do make style changes, put them in a separate commit at the very least so the diffs are cleaner and code reviews are easier.
In my project I use gofmt (goimports) for back-end code and prettier for front-end; I've configured my editor to apply those on save, and a pre-commit hook to either run the formatter, or error if the formatting is not according to the spec.
One of Go's proverbs is "Gofmt's style is no one's favorite, yet gofmt is everyone's favorite.". Consistency and low noise is more important (in that case) than a specific code style preference.
gofmt is in a small set of formatters that disallows configuration and choice, it's also the first to my recollection. This is a feature because deciding on a coding standard is bike shedding. It's also extremely aggressive, and undoes pretty much any choice you may make in formatting your code; a feature, again.
Not all languages are this fortunate. Some have configuration (cargo fmt), others aren't aggressive enough (Roslyn).
Given the code:
foo(one, two, three);
If you add an argument and reformat: foo(
one,
two,
new,
three
);
A line-based diff can make it hard to spot what's changed.For the same reason, I asciibetically sorted things when it made sense.
Now I use prettier and black and I'm mostly satisfied by them, but their reflow behavior puts the lie to "[black] makes code review faster by producing the smallest diffs possible."
A similar Python tool is Black: https://github.com/psf/black
> Black makes code review faster by producing the smallest diffs possible.