三元运算符周围是否应该始终放置括号？
Checkstyle 抱怨以下内容：
return (null == a ? a : new A());
并表示括号是不必要的。
虽然在没有它们的情况下，该声明当然可以正常工作，但在有它们存在的情况下，它似乎更具可读性——否则，当我阅读它时，我倾向于看到：
return null
首先，然后必须停下来考虑剩余
== a ? a : new A();
部分，因为我的大脑已经消失了沿着一条路。
此外，每当我看到三元运算符时，我都会做同样的事情，除非它分组在括号中。
那么：三元周围的括号应该成为事实上的标准吗？有什么理由不把它们放在那里吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
嗯，checkstyle是对的，括号对执行没有用。但对执行无用并不意味着对代码的良好阅读无用。如果阅读起来更有意义，您应该离开它们。
我认为这段代码不需要更多的括号：
但在您的情况下，
return关键字以及您的布尔值是一个表达式的事实可以改变您阅读语句的方式。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:
but in your case the
returnkeyword and the fact your boolean is an expression can change the way you read the statement.当阅读 return 语句时，我知道 'return' 和 ';' 之间的所有内容是要返回的内容，所以我无法将您的代码示例读取为 return null 后跟一些符号，正如您声称您阅读的那样。
也许阅读解析技术可能会帮助您像我一样看待它。也就是说，我并没有真正阅读过解析技术，尽管多年来我已经拼凑了一些解析器。
我总是删除不必要的括号。它们对代码理解没有帮助，因为我非常了解 Java 的运算符优先级。有时我不确定，我会添加括号并等待 IDEA 是否告诉我它们是多余的。然后我删除它们，并尝试记住我刚刚发现的优先规则。
在我继承的代码库中，我倾向于在因其他原因而较差的代码区域中找到最多数量的冗余括号，因此我将两者关联起来。
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.
不，它不应该成为事实上的标准。我更喜欢没有括号的。
我认为将它们放在那里的唯一原因是强制执行评估命令或澄清令人困惑的界限。
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.
两个选项都是正确的，使用您的团队使用的内容或您单独工作时喜欢的内容。
IIRC 默认情况下，checkstyle 使用 Sun 的 (rip) 样式指南，因此如果您想符合标准样式，请听取它并删除括号。
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 (r.i.p) style guidelines, so if you want to conform to standard style, listen to it and remove the parens.
一般来说，不。
三元（也称为条件）运算符或其部分不需要括号，因为它们的优先级在运算顺序中非常低（位于逻辑运算符下方和赋值上方）。请参阅下面的链接查看完整表格。
因此，可以说，这种不必要的括号在视觉上使代码变得混乱，并且它们暴露了程序员缺乏理解。
可能需要在三元数中或周围使用括号的例外情况是：
如果您的三元数足够复杂，需要多行；然后，您可以将语句括在括号中，以防止自动插入分号。
如果您的三元数嵌套在另一个三元数中。
另请参阅 MDN：
运算符优先级（顺序操作）
条件 (三元）运算符
自动分号插入
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
在三元运算符两边加上括号有两个很好的理由。
许多人认为它更具可读性。如果您也这样做，请将括号放入。仅有时将它们放入是愚蠢的 - 保持一致。
缺少括号可能会导致操作顺序不正确，尤其是在以后修改代码时。这类似于忘记预处理器宏周围的括号。考虑一下下面的第二个语句给出的结果与第一个语句不同。
int num = (true ? val1 : val2) * 2;
整数数=真？值1：值2 * 2；
There are two good reasons to put parentheses around ternary operators.
Many people consider it more readable. If you do too, put the parens in. Putting them in only sometimes is silly -- be consistent.
Missing parens can lead to incorrect operation order, especially when code is modified later. This is similar to forgetting parentheses around preprocessor macros. Consider that the second statement below gives a different result than the first.
int num = (true ? val1 : val2) * 2;
int num = true ? val1 : val2 * 2;
由于您的问题的基础与阅读代码的行为有关，因此我将从这个角度来处理这个问题。
所谓的“快速阅读”培训计划的基本原则之一是，它们试图让读者形成文本行的完形，而不是逐字顺序阅读。您可能会尝试从他们的书中取出一页，然后从您的代码中退一步（如果有必要的话），以了解整行内容，而不是将阅读行为视为逐个解析标记的行为。
或者，您可以使用可让您配置样式的编辑器：您可以将三元运算符设置为不同的颜色，以便它在您面前脱颖而出。例如，Notepad++ 有许多内置主题可以执行此操作，许多其他编辑器也是如此。
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.