Hacker News new | past | comments | ask | show | jobs | submit login

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




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.


That's my main concern, I want to review the changes, not formatting opinions.


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?


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


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


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: