`exceptRange` (or `exceptYodaRange`) option for `no-extra-parens`

What version are you using?

Version on demo.

What did you do?

I added the following code, adapted from the non-problematic range sample from yoda:

/*eslint yoda: [2, "never", { "exceptRange": true }]*/

function isReddish(color) {
    return (color.hue < 60 || 300 < color.hue);
}

What happened?

A no-extra-parens error is reported.

What did you expect to happen?

While it is expected that it still reports a no-extra-parens, I’d think that no-extra-parens should have its own “exceptRange” option (or “exceptYodaRange”), so that someone wishing not to normally allow them could allow them in the case of ranges.

[platinumazure]

Why does yoda require parentheses for this exceptional case, anyway? The whole point of the range exception should be that the first half of an or conditional, using the same identifier or member expression on both sides, is allowed to be yoda-style to make the condition more readable as a range. Parentheses should not be enforced here- the fact that they are is a sign that this rule is not following the Single Responsibility Principle. I would champion an enhancement for removing that check, so that this rule has less of a chance to collide with no-extra-parens.

[platinumazure]

@btmills I can respect the virtue of clarity and I’m not opposed to having a way of enforcing it. I just don’t think the Yoda rule is the right place to do it and that we should write a new rule that focuses on clarity of logical expressions. But that’s just my opinion. On Mar 19, 2016 3:23 PM, “Brandon Mills” [e-mail] wrote:

If (1) is deemed insufficient, (2) from a technical perspective certainly isn’t insurmountable if someone wants to tackle it.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/eslint/eslint/issues/5575#issuecomment-198779453