Consider disabling the rule that removes 'unnecessary' brackets in basic operator expressions, or make it optional.

Prettier 1.19.1 Playground link

--parser babel

Input:

const totalCost = fixed + (monthly * 12);

Output:

const totalCost = fixed + monthly * 12;

Expected behavior:

Maintain the parentheses for readability.

There are many expressions that rely on knowledge of explicit operator precedence. While technically they are unambiguous, we have recently proven in a code readability experiment that adding parenthesis improves readability.

The example above was included in our experiment that A/B tested code snippets on developers, and directly measured how easily they read the code. The data showed that by adding parentheses, there was a statistically significant improvement in speed of reading the code and accuracy in understanding it.

The findings are available here:

https://howreadable.netlify.com/results/#operator-precedence

The rule appears to be based on https://eslint.org/docs/rules/no-extra-parens. I have separately requested that rule to be amended based on the results.

[dvberzon]

@thorn0

I apologise for the references to ESlint. I can’t find any documentation in prettier for the list of rules that are applied, so I took my queue from #187 which mentions no-mixed-operators. If this is actually a prettier rule then I apologise, I wasn’t able to find it.

My understanding of prettier’s philosophy was to be opinionated about style decisions - decisions which do not affect the quality of the code - and to NOT make any changes based on code quality. I took this from the documentation: https://prettier.io/docs/en/comparison.html (a link which by the way has many references to ESlint!)

The point I’m trying to make is that by removing parentheses, prettier is unintentionally affecting the quality of the code. Our results show that expressions which rely on operator precedence are more readable with parentheses.

https://howreadable.netlify.com/results/#operator-precedence

I agree that in these cases, the parentheses don’t affect the syntactical structure of the code - much like whitespace. However, prettier would never consider removing line breaks and putting all the code on one line. it would massively reduce the code’s readability (whilst still being syntactically correct). I’m asking for similar consideration with parentheses.

[thorn0]

Thanks for your unusual and valuable input. However, we are really reluctant to extend that list of exceptional cases where Prettier looks at the original formatting. It’s even planned to add an option to ignore the input formatting completely.

Readability is not the only constituent of Prettier’s value proposition. What about the goal of avoiding style debates within teams? Keeping the original formatting is a way away from this goal. With Prettier, such readability issues aren’t the developer’s responsibility anymore. The team simply agrees to delegate those formatting matters to Prettier and focuses on more interesting things. This comes with certain trade-offs, sure, but some say it’s worth it.

Of course, we welcome readability improvements, but not when they come at the cost of compromising other values of the project.