是否应该在三元运算符周围放置括号？

Question

Checkstyle complains about the following:

return (null == a ? a : new A());

and says the parens are unnecessary.

While the statement certainly works fine without them, it seems far more readable with them present---otherwise as I'm reading it I tend to see:

return null

first and then have to pause to consider the remaining

== a ? a : new A(); 

part, since my brain has already gone down one path.

Furthermore, I tend to do the same thing whenever I see a ternary operator, unless it is grouped in parens.

So: should parens around the ternary be the de facto standard? Is there ever any reason to not put them there?

Answer 1

Well, checkstyle is right, the parentheses are useless for the execution. But useless for the execution doesn't mean useless for the good reading of your code. You should leave them if it makes more sense to read.

I think this code doesn't need more parentheses:

int number = (myBoolean)? 1 : 2;

but in your case the return keyword and the fact your boolean is an expression can change the way you read the statement.

Answer 2

When reading a return statement, I know that everything between 'return' and ';' is what is going to be returned, so there is no way I can read your code sample as return null followed by some symbols as you claim you read it.

Perhaps reading up on parsing techniques might help you to see it as I do. That said, I haven't really read up on parsing techniques, though I've cobbled a few parsers together over the years.

I always remove unnecessary parentheses. They don't aid in code comprehension, as I know Java's operator precedence pretty well. The odd time I'm unsure, I add parentheses and wait to see whether IDEA tells me they're redundant. Then I remove them, and try to commit to memory the precedence rule I've just discovered.

In the codebases I inherited, I tend to find the greatest number of redundant parentheses in areas of code that are poor for other reasons, so I associate the two.

Answer 3

No, it should not be the de facto standard. I prefer it without parens.

I think the only reason to put them there is to force evaluation order or to clarify a confusing line.

Answer 4

Both options are correct, use what your team uses or what you like if you are working alone.

IIRC By default checkstyle uses Sun's (rip) style guidelines, so if you want to conform to standard style, listen to it and remove the parens.

Answer 5

In general, no .

Parentheses are not required around ternary (also known as conditional) operators or its sections, because their precedence is so very low in the order of operations (just below logical operators and above assignments). See the link below for the full table.

It could be argued, therefore, that such unnecessary parens visually clutter the code, and they reveal a lack of comprehension on the part of the programmer.

Exceptions that might require use of parens in or around ternaries would be:

• If your ternary is complex enough to merit multiple lines; you might then surround your statement in parens in order to prevent automatic semicolon insertion.

• If your ternary is nested within another ternary.

See also on MDN:

• Operator precedence (order of operations)

• Conditional (ternary) operator

• Automatic semicolon insertion

Answer 6

Since the basis for your question has to do with the act of reading code, I'll approach the question from that perspective.

One of the basic principles of so-called "speed-reading" training programs is that they try to get the reader to develop a gestalt of the line of text rather than reading it sequentially word-by-word . You might try to take a page from their book and step back from your code -- literally if necessary-- to get a sense of the full line rather than treating the act of reading as if it were the act of parsing token by token.

Alternatively, you could use an editor that lets you configure styles: you could make the ternary operator a different color so it jumps out at you. Notepad++, for example, has a number of built-in themes that do this, as do many other editors.