3 ms·

You're argueing something completely different. I never mentioned anything about autoformatters. That said, any autoformatter will need to strike a careful bal

by arp242 3y ago

You're argueing something completely different. I never mentioned anything about autoformatters. That said, any autoformatter will need to strike a careful balance or it will produce nonsense: too little enforcement makes the tool useless, and too much will just crapify things. gofmt mostly gets it right, but I've never been able to get clang-format to produce something reasonable. I don't know about Python, as I don't do much Python.

jaktet 3y ago
I wouldn’t say they’re arguing something completely different. A large subset of linting rules are by nature purely formatting rules. You can enforce line length with either prettier or a linter and both can auto fix the issue. Because of this things like [`eslint-config-prettier`](https://github.com/prettier/eslint-config-prettier https://github.com/prettier/eslint-config-prettier) exist to ensure conflicting eslint formatting rules are disabled if they can be handled by prettier.
- arp242 3y ago
  > You can enforce line length with either prettier or a linter and both can auto fix the issue. It's not about whether it's automatic or not, it's about the code being worse (that is: harder to read). Breaking lines because it's 1 character over some arbitrary limit is almost always bad, whether it's automatic or manual.
  - sanderjd 3y ago
    A human ever thinking about where to break a line is bad. Let the computers do that, in one standard way for a project, and never think or talk about it again. The amount of time people have wasted on trivia like this over the decades is astronomical. It doesn't matter what the answer is, pick one, make it automatic, and move on.
    - morelisp 3y ago
      Both things are true. It's worth arguing about so infrequently it's never worth thinking about whether it's worth arguing about, let alone argue about; but automated tools still make decisions far worse than any human would make sometimes.
    - TillE 3y ago
      Yeah I'm always delighted to use clang-format rather than worry about where I should put the brackets. Code style is the epitome of bikeshedding. Anything consistent is fine, and using a tool to automate that is a huge productivity win.

by arp242 3y ago

jaktet 3y ago

I wouldn’t say they’re arguing something completely different. A large subset of linting rules are by nature purely formatting rules. You can enforce line length with either prettier or a linter and both can auto fix the issue. Because of this things like [`eslint-config-prettier`](https://github.com/prettier/eslint-config-prettier https://github.com/prettier/eslint-config-prettier) exist to ensure conflicting eslint formatting rules are disabled if they can be handled by prettier.

arp242 3y ago
> You can enforce line length with either prettier or a linter and both can auto fix the issue. It's not about whether it's automatic or not, it's about the code being worse (that is: harder to read). Breaking lines because it's 1 character over some arbitrary limit is almost always bad, whether it's automatic or manual.
- sanderjd 3y ago
  A human ever thinking about where to break a line is bad. Let the computers do that, in one standard way for a project, and never think or talk about it again. The amount of time people have wasted on trivia like this over the decades is astronomical. It doesn't matter what the answer is, pick one, make it automatic, and move on.
  - morelisp 3y ago
    Both things are true. It's worth arguing about so infrequently it's never worth thinking about whether it's worth arguing about, let alone argue about; but automated tools still make decisions far worse than any human would make sometimes.
  - TillE 3y ago
    Yeah I'm always delighted to use clang-format rather than worry about where I should put the brackets. Code style is the epitome of bikeshedding. Anything consistent is fine, and using a tool to automate that is a huge productivity win.