I think code formatting should be mandatory and one of the first things you adopt in your project. Resist code style rule changes as much as possible, and if you do, apply them across the whole codebase in one go to avoid churn and noise in diffs down the line.

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.

And if you do decide to do single-commit massive style changes, add the commits to an ignore revs file: http://git-scm.com/docs/git-config#Documentation/git-config....

Did not know that thing existed, super useful. Thanks a ton.

> gofmt

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).

you might want to check out gofumpt too, if you haven't already: https://github.com/mvdan/gofumpt

A syntactic differ like Difftastic is very helpful when your codebase is autoformatted. Formatters often reflow code.

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.

When I was still formatting code manually (... -ish; emacs did a lot of the tedious work for me) I eventually settled on a style very similar to your four-argument example, precisely because it makes diffs easier to read.

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."

Prettier works for JS.

A similar Python tool is Black: https://github.com/psf/black

> Black makes code review faster by producing the smallest diffs possible.

This worsens the problem especially in templates when the nesting changes.

Good diff tools will only show you that the indentation changed, not the line as a whole (Meld for example).