5 ms·

To ease the pain in conventional differs, we use a pre-commit hook to format the source code (prettier). This way we only see differences if something _actually

To ease the pain in conventional differs, we use a pre-commit hook to format the source code (prettier). This way we only see differences if something _actually_ changed.

danuker 5y ago
Prettier works for JS. A similar Python tool is Black: https://github.com/psf/black https://github.com/psf/black > Black makes code review faster by producing the smallest diffs possible.
Cthulhu_ 5y ago
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.
- TotempaaltJ 5y ago
  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.txt-blameignoreRevsFile http://git-scm.com/docs/git-config#Documentation/git-config....
  - lpapez 5y ago
    Did not know that thing existed, super useful. Thanks a ton.
- llimllib 5y ago
  you might want to check out gofumpt too, if you haven't already: https://github.com/mvdan/gofumpt https://github.com/mvdan/gofumpt
- zamalek 5y ago
  > 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).
conceptme 5y ago
This worsens the problem especially in templates when the nesting changes.
- frafra 5y ago
  Good diff tools will only show you that the indentation changed, not the line as a whole (Meld for example).
Wilfred 5y ago
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.
- maw 5y ago
  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."

To ease the pain in conventional differs, we use a pre-commit hook to format the source code (prettier). This way we only see differences if something _actually_ changed.

danuker 5y ago

Prettier works for JS. A similar Python tool is Black: https://github.com/psf/black https://github.com/psf/black > Black makes code review faster by producing the smallest diffs possible.

Cthulhu_ 5y ago

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.

TotempaaltJ 5y ago
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.txt-blameignoreRevsFile http://git-scm.com/docs/git-config#Documentation/git-config....
- lpapez 5y ago
  Did not know that thing existed, super useful. Thanks a ton.
llimllib 5y ago
you might want to check out gofumpt too, if you haven't already: https://github.com/mvdan/gofumpt https://github.com/mvdan/gofumpt
zamalek 5y ago
> 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).

conceptme 5y ago

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

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

Wilfred 5y ago

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.

maw 5y ago
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."