Third option for Style/TernaryParentheses

[benhutton]

Currently (as of 0.42.0), rubocop gives 2 options for Style/TernaryParentheses

EnforcedStyle: require_no_parentheses (deafault)

@bad
foo = (bar?) ? a : b
foo = (bar.baz) ? a : b
foo = (bar && baz) ? a : b

@good
foo = bar? ? a : b
foo = bar.baz? ? a : b
foo = bar && baz ? a : b

and

EnforcedStyle: require_parentheses

@bad
foo = bar? ? a : b
foo = bar.baz? ? a : b
foo = bar && baz ? a : b

@good
foo = (bar?) ? a : b
foo = (bar.baz) ? a : b
foo = (bar && baz) ? a : b

Both of these are undesirable to our team...

Sometimes, parens are desired—the conditional is complex and the timing is not quite right to do a proper refactor. Parentheses greatly aid legibility and code comprehension and scannability. (Quick test: without looking, in Ruby's order of operations precedence, where does a ternary operator fall? How does it compare to &&? How about to =? What about to defined??)

Usually, parens are unnecessary. Which is why require_no_parentheses was chosen as the default, I'm sure.

So, what I'd like to see is a third option:

EnforcedStyle: require_parentheses_when_complex

@bad
foo = (bar?) ? a : b
foo = (bar.baz?) ? a : b
foo = bar && baz ? a : b

@good
foo = bar? ? a : b
foo = bar.baz ? a : b
foo = (bar && baz) ? a : b

Namely, I want to require parens when there is a non-unary operator as the first term in the ternary operator.

What do ya'll think?

[bbatsov]

Makes sense to me. I'd accept such a style if someone implements it.

[Drenmi]

This is a clear improvement from a similar suggestion made earlier, in that this one specifies, unambiguously, what "complex" means, but the suggested configuration name unfortunately doesn't give the user much indication of its specifics. 😀

[benhutton]

@Drenmi by "complex" I was thinking the more basic definition of "compound":

Not necessarily "complicated", though that is part of the semantic range, too.

What about the word "compound"? So, require_parentheses_when_compound?

[Drenmi]

I think whatever we come up with will be not specific enough, lest we make the name prohibitively long. 😅 I think let's just go with "complex", and include an explanation of the setting in default.yml. 😀

[swcraig]

I have the cop working for this and will commit somewhat soon.