4 ms·

Prettier doesn't resolve my primary issue with excessive linting rules. The way I see it, there are three kinds of syntax linting rules: 1) Potential bugs. T

Prettier doesn't resolve my primary issue with excessive linting rules. The way I see it, there are three kinds of syntax linting rules: 1) Potential bugs. These are where a syntax will technically work, but makes it easy for an unintended bug to creep in. Most everyone agrees that these are bad. (There are a few arguments about what qualifies, but this is nonetheless a less-argued-about category. 2) Purely stylistic. This is where Prettier shines, because everyone wants the "more readable" option - where "readable" means "more familiar". Prettier allows you to write your preferred style, though of course anything you READ will be in the defined style (absent two-way conversion). 3) Expressiveness. This is where you're formatting your code to communicate. While Perl is notorious for this - the advocates love it because well-written code is easy to follow and maintain and the detractors hate it because just because you CAN write clearly in it, the skill to do so is rarely developed and the result is near-gibberish, even from skilled coders - like a story that has every sentence written by a different person. Java is the reverse - the advocates love it because the code tends to be very uniform and the detractors hate it because it's universally verbose and unclear. That last category is why I'm leery of excessive linting. If I'm dealing with code that changes hands often, a Java style makes sense - newspapers written for a low but common reading level, even if the reader is capable of much more nuance. In this scenario nuance would risk being ignored, or worse, being mis-applied, which means the result would be misleading. If I'm dealing with code that is owned by a team that has routine staffing changes but no complete upsets, nuance has a real benefit - reading code is faster and more accurate/informative, with the result of fewer bugs (citation needed). But saying "It's okay to use Prettier and stop arguing about linting" dismisses the nuanced case. It carries the assumption that linting rules - any rules - are automatically valuable regardless of the choices made, and if you don't like it than write what you like and just use Prettier. Linting rules (and linting arguments) exist for a reason - these are LANGUAGES that we are using to communicate - and as much as I'm tired of the arguments too, until we honestly figure out how to communicate well, ignoring the arguments doesn't help.

khalilravanna 8y ago
I agree that nuance and discussion about style is incredibly important because, as you aptly point out, we're writing in a language used for communication. That being said, since we've introduced Prettier, I haven't encountered any changes it's made to code that are anything more than trivial formatting/purely-stylistic changes. I think readability and expressiveness are more about larger scale patterns in code writing (writing self-documenting code with descriptive variable and function names, writing modular code, etc). These are things that should be continuously discussed and improved upon for clarity and alignment. The really granular formatting changes that Prettier chiefly concerns itself with don't seem to be a concern in this case. If you could point me at a more specific case where you think Prettier mucks things up I'd love to see more of what you're talking about.
- ergothus 8y ago
  I could be misunderstanding (I've not yet used Prettier), but I thought Prettier was agnostic to the linting rules used. I was arguing not that Prettier is bad, but the _excessive_ linting rules were bad (Prettier should be fine for reducing arguments over trivial rules that neither impact bugs nor expressiveness), and further, that arguing that excessive linting wasn't a problem because Prettier can let you ignore them is likewise bad. None of which says that Prettier itself is bad, but that excessive linting rules, with or without Prettier, are bad. If I'm wrong about what Prettier does, please let me know. If you're discussing a default set of linting rules Prettier uses, cool, but I can't really say if I think they impact expressiveness since I'm not familiar with that set of rules.
  - jacobwg 8y ago
    I think you are misunderstanding what Prettier does - Prettier is more in line with gofmt as it is a formatter not a linter. Prettier parses the JS code into an abstract syntax tree and then outputs that AST back into code using a defined set of rules, so you end up with one unified style. Prettier intentionally doesn't give you many configuration options for this style, with the goal of eliminating the discussion about which style to use. If you are using Prettier, you can use the Prettier config with eslint or tslint, which fully disables the style rules for those two linters and lets them focus solely on linting for errors and structural issues.
    - ergothus 8y ago
      Ah, I thought it consumed the style rules and rewrote to them, so you could pick your preferred styles and have everyone submit code that met them even if they didn't write in that way. Which sounds mostly correct, except for the "pick" part.

khalilravanna 8y ago

I agree that nuance and discussion about style is incredibly important because, as you aptly point out, we're writing in a language used for communication. That being said, since we've introduced Prettier, I haven't encountered any changes it's made to code that are anything more than trivial formatting/purely-stylistic changes. I think readability and expressiveness are more about larger scale patterns in code writing (writing self-documenting code with descriptive variable and function names, writing modular code, etc). These are things that should be continuously discussed and improved upon for clarity and alignment. The really granular formatting changes that Prettier chiefly concerns itself with don't seem to be a concern in this case. If you could point me at a more specific case where you think Prettier mucks things up I'd love to see more of what you're talking about.

ergothus 8y ago
I could be misunderstanding (I've not yet used Prettier), but I thought Prettier was agnostic to the linting rules used. I was arguing not that Prettier is bad, but the _excessive_ linting rules were bad (Prettier should be fine for reducing arguments over trivial rules that neither impact bugs nor expressiveness), and further, that arguing that excessive linting wasn't a problem because Prettier can let you ignore them is likewise bad. None of which says that Prettier itself is bad, but that excessive linting rules, with or without Prettier, are bad. If I'm wrong about what Prettier does, please let me know. If you're discussing a default set of linting rules Prettier uses, cool, but I can't really say if I think they impact expressiveness since I'm not familiar with that set of rules.
- jacobwg 8y ago
  I think you are misunderstanding what Prettier does - Prettier is more in line with gofmt as it is a formatter not a linter. Prettier parses the JS code into an abstract syntax tree and then outputs that AST back into code using a defined set of rules, so you end up with one unified style. Prettier intentionally doesn't give you many configuration options for this style, with the goal of eliminating the discussion about which style to use. If you are using Prettier, you can use the Prettier config with eslint or tslint, which fully disables the style rules for those two linters and lets them focus solely on linting for errors and structural issues.
  - ergothus 8y ago
    Ah, I thought it consumed the style rules and rewrote to them, so you could pick your preferred styles and have everyone submit code that met them even if they didn't write in that way. Which sounds mostly correct, except for the "pick" part.