4 ms·

> Most places I've worked in the last 6 or so years are obsessed with tooling and add so many lint rules that it's often impossible to merge your pull request i

> Most places I've worked in the last 6 or so years are obsessed with tooling and add so many lint rules that it's often impossible to merge your pull request if you decide to format your code in a way that violates the rules in some trivial way. Shouldn't all the lines of code uploaded in a pull request be automatically formatted into the coding style preferred by the reviewer anyway? It should be like an automatic translation done by some bot or something.

sokoloff 2y ago
That desire is in conflict with a desire for the reviewer to see only the changes and many of the diff tools don’t diff this reformatted code against that reformatted code but rather work on the pre-reformatted. It could obviously be done, but involves a yak shave that isn’t clear that it brings enough value to be worthwhile.
- swader999 2y ago
  That's my main concern, I want to review the changes, not formatting opinions.
  - worik 2y ago
    I do not get it. If it is formatted to the formatting rules before every commit, how can there ever be formatting opinions? What am I missing?
vbezhenar 2y ago
What bot? You create a branch, you push button in github UI, merge request is created. There's no bot.
- Shacklz 2y ago
  It's not a bot but formatters like prettier for example make it very easy to set them up as git-hooks, where the formatter is applied on commit. Meaning, unless you specifically commit without hooks, all committed code should comply with the formatter. For linting (e.g. eslint in the JS-space), this is also possible, however, most linting-processes tend to run just long enough to be annoying when run on every commit. In the monorepo I work on we created a command "prep-pr" which specifically addresses this issue - run it before creating a PR, and the CI-pipeline will mostly be green, at least in terms of linting/unit-testing.
wombat-man 2y ago
We can't check in anything that fails the linter, but we can also automatically format the code very easily.

sokoloff 2y ago

That desire is in conflict with a desire for the reviewer to see only the changes and many of the diff tools don’t diff this reformatted code against that reformatted code but rather work on the pre-reformatted. It could obviously be done, but involves a yak shave that isn’t clear that it brings enough value to be worthwhile.

swader999 2y ago
That's my main concern, I want to review the changes, not formatting opinions.
- worik 2y ago
  I do not get it. If it is formatted to the formatting rules before every commit, how can there ever be formatting opinions? What am I missing?

vbezhenar 2y ago

What bot? You create a branch, you push button in github UI, merge request is created. There's no bot.

Shacklz 2y ago
It's not a bot but formatters like prettier for example make it very easy to set them up as git-hooks, where the formatter is applied on commit. Meaning, unless you specifically commit without hooks, all committed code should comply with the formatter. For linting (e.g. eslint in the JS-space), this is also possible, however, most linting-processes tend to run just long enough to be annoying when run on every commit. In the monorepo I work on we created a command "prep-pr" which specifically addresses this issue - run it before creating a PR, and the CI-pipeline will mostly be green, at least in terms of linting/unit-testing.

wombat-man 2y ago

We can't check in anything that fails the linter, but we can also automatically format the code very easily.