blocks|key|1517012|text|在我看来，只有在需要表达式的情况下使用三元运算符才有意义。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1517013|在其他情况下，三元运算符似乎降低了清晰度。|1517014|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

In my mind, it only makes sense to use the ternary operator in cases where an expression is needed.

In other cases, it seems like the ternary operator decreases clarity.

blocks|key|1732078|text|我经常在我被限制在构造函数中工作的地方使用它-例如，新的.NET+3.5LINQ+to+XML构造-在可选参数为null时定义默认值。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1732079|人为设计的例子：|1732080|var+e+=+new+XElement("Something",
++++param+==+null+?+new+XElement("Value",+"Default")
++++++++++++++++++:+new+XElement("Value",+param.ToString())
);|code-block|syntax|javascript|1732081|或者(感谢asterite)|1732082|var+e+=+new+XElement("Something",
++++new+XElement("Value",
++++++++param+==+null+?+"Default"
++++++++++++++++++++++:+param.ToString()
++++)
);|1732083|不管你是否使用三元运算符，确保你的代码是可读的是很重要的。任何结构都可以变得不可读。|1732084|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|S|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|T|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|U|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|V|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

I use it quite often in places where I'm constrained to work in a constructor - for example, the new .NET 3.5 LINQ to XML constructs - to define default values when an optional parameter is null.

Contrived example:

<pre><code>var e = new XElement("Something",
 param == null ? new XElement("Value", "Default")
 : new XElement("Value", param.ToString())
);
</code></pre>

or (thanks asterite)

<pre><code>var e = new XElement("Something",
 new XElement("Value",
 param == null ? "Default"
 : param.ToString()
 )
);
</code></pre>

No matter whether you use the ternary operator or not, making sure your code is readable is the important thing. Any construct can be made unreadable.

blocks|key|1517080|text|我对待三元运算符很像GOTO。它们有自己的位置，但为了使代码更容易理解，您通常应该避免使用它们。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1517081|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I treat ternary operators a lot like GOTO. They have their place, but they are something which you should usually avoid to make the code easier to understand.

blocks|key|1517111|text|这使得调试变得稍微困难一些，因为您不能在每个子表达式上都放置断点。我很少用到它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1517112|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

It makes debugging slightly more difficult since you can not place breakpoints on each of the sub expressions. I use it rarely.

blocks|key|1517139|text|我同意jmulder的观点:它不应该用来代替if，但它在返回表达式或表达式中有自己的位置：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1517140|echo+"Result:+"+%2B+n+%2B+"+meter"+%2B+(n+!=+1+?+"s"+:+"");
return+a+==+null+?+"null"+:+a;|code-block|syntax|javascript|1517141|前者只是一个例子，应该使用更好的复数internationalisation+and+localisation支持！|1517142|entityMap|0|LINK|mutability|MUTABLE|url|https://en.wikipedia.org/wiki/Internationalization_and_localization^0|M|2|0|0|I|11|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@$9|V|A|W|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|X|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|Y|8|@]|D|@$9|Z|A|10|1|11]]|E|$]]|$1|M|3|-4|5|6|7|12|8|@]|D|@]|E|$]]]|N|$O|$5|P|Q|R|E|$S|T]]]]

I agree with jmulder: it shouldn't be used in place of a <code>if</code>, but it has its place for return expression or inside an expression:
<pre><code>echo &quot;Result: &quot; + n + &quot; meter&quot; + (n != 1 ? &quot;s&quot; : &quot;&quot;);
return a == null ? &quot;null&quot; : a;
</code></pre>
The former is just an example, and better <a href="https://en.wikipedia.org/wiki/Internationalization_and_localization" rel="nofollow noreferrer">internationalisation and localisation</a> support of plural should be used!

blocks|key|1732206|text|我尽可能地使用三元运算符，除非它使代码非常难以阅读，但这通常只是表明我的代码可以进行一些重构。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1732207|有些人认为三元运算符是一个“隐藏”的功能，或者有点神秘，这总是让我感到困惑。这是我开始用C语言编程时学到的第一件事，我不认为它会降低可读性。这是语言的一个自然部分。|1732208|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I use the ternary operator wherever I can, unless it makes the code extremely hard to read, but then that's usually just an indication that my code could use a little refactoring.
It always puzzles me how some people think the ternary operator is a &quot;hidden&quot; feature or is somewhat mysterious. It's one of the first things I learnt when I start programming in C, and I don't think it decreases readability at all. It's a natural part of the language.

blocks|key|1732311|text|我认为应该在需要的时候使用三元运算符。这显然是一个非常主观的选择，但我发现一个简单的表达式(特别是作为一个返回表达式)比一个完整的测试要清晰得多。C/C%2B%2B中的示例：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1732312|return+(a>0)?a:0;|code-block|syntax|javascript|1732313|对比：|1732314|if(a>0)+return+a;
else+return+0;|1732315|您还会遇到解决方案介于三元运算符和创建函数之间的情况。例如在Python中：|1732316|l+=+[+i+if+i+>+0+else+0+for+i+in+lst+]|1732317|另一种选择是：|1732318|def+cap(value):
++++if+value+>+0:
++++++++return+value
++++return+0
l+=+[+cap(i)+for+i+in+lst+]|1732319|在Python中(以Python为例)，可以经常看到这样一种习惯用法：|1732320|l+=+[+((i>0+and+[i])+or+[0])[0]+for+i+in+lst+]|1732321|这一行使用了Python中逻辑运算符的属性:它们是惰性的，如果它等于最终状态，则返回计算出的最后一个值。|1732322|entityMap^0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|11|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|12|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|13|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|14|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|15|8|@]|9|@]|A|$E|F]]|$1|O|3|P|5|6|7|16|8|@]|9|@]|A|$]]|$1|Q|3|R|5|D|7|17|8|@]|9|@]|A|$E|F]]|$1|S|3|T|5|6|7|18|8|@]|9|@]|A|$]]|$1|U|3|V|5|D|7|19|8|@]|9|@]|A|$E|F]]|$1|W|3|X|5|6|7|1A|8|@]|9|@]|A|$]]|$1|Y|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]]|Z|$]]

I think the ternary operator should be used when needed. It is obviously a very subjective choice, but I find that a simple expression (specially as a return expression) is much clearer than a full test. Example in C/C++:

<pre><code>return (a&gt;0)?a:0;
</code></pre>

Compared to:

<pre><code>if(a&gt;0) return a;
else return 0;
</code></pre>

You also have the case where the solution is between the ternary operator and creating a function. For example in Python:

<pre><code>l = [ i if i &gt; 0 else 0 for i in lst ]
</code></pre>

The alternative is:

<pre><code>def cap(value):
 if value &gt; 0:
 return value
 return 0
l = [ cap(i) for i in lst ]
</code></pre>

It is needed enough that in Python (as an example), such an idiom could be seen regularly:

<pre><code>l = [ ((i&gt;0 and [i]) or [0])[0] for i in lst ]
</code></pre>

this line uses properties of the logical operators in Python: they are lazy and returns the last value computed if it is equal to the final state.

blocks|key|1517370|text|我喜欢在调试代码中使用运算符来打印错误值，这样我就不必一直查找它们。通常，我这样做是为了调试打印，一旦我完成开发，这些打印就不会保留下来。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1517371|int+result+=+do_something();
if(+result+!=+0+)
{
++debug_printf("Error+while+doing+something,+code+%25x+(%25s)\n",+result,
++++++++++++++++result+==+7+?+"ERROR_YES"+:
++++++++++++++++result+==+8+?+"ERROR_NO"+:
++++++++++++++++result+==+9+?+"ERROR_FILE_NOT_FOUND"+:
++++++++++++++++"Unknown");
}|code-block|syntax|javascript|1517372|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

I like using the operator in debug code to print error values so I don't have to look them up all the time. Usually I do this for debug prints that aren't going to remain once I'm done developing.

<pre><code>int result = do_something();
if( result != 0 )
{
 debug_printf("Error while doing something, code %x (%s)\n", result,
 result == 7 ? "ERROR_YES" :
 result == 8 ? "ERROR_NO" :
 result == 9 ? "ERROR_FILE_NOT_FOUND" :
 "Unknown");
}
</code></pre>

blocks|key|1517471|text|我是它的铁杆粉丝...在适当的时候。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1517472|像这样的东西很棒，就我个人而言，我并不觉得阅读/理解它太难：|1517473|$y+=+($x+==+"a"+?+"apple"
+++:+($x+==+"b"+?+"banana"
+++:+($x+==+"c"+?+"carrot"
+++:+"default")));|code-block|syntax|javascript|1517474|不过，我知道这可能会让很多人感到害怕。|1517475|在PHP中使用它时需要记住的一件事是，它是如何处理返回引用的函数的。|1517476|class+Foo+{
++++var+$bar;

++++function+Foo()+{
++++++++$this->bar+=+"original+value";
++++}

++++function+&tern()+{
++++++++return+true+?+$this->bar+:+false;
++++}

++++function+&notTern()+{
++++++++if+(true)+return+$this->bar;
++++++++else++++++return+false;
++++}
}

$f+=+new+Foo();
$b+=&+$f->notTern();
$b+=+"changed";
echo+$f->bar;++//+"changed"

$f2+=+new+Foo();
$b2+=&+$f->tern();
$b2+=+"changed";
echo+$f2->bar;++//+"original+value"|1517477|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|S|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|T|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|U|8|@]|9|@]|A|$]]|$1|M|3|N|5|F|7|V|8|@]|9|@]|A|$G|H]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

I'm a big fan of it ... when appropriate.
Stuff like this is great, and, personally, I don't find it too hard to read/understand:
<pre><code>$y = ($x == &quot;a&quot; ? &quot;apple&quot;
 : ($x == &quot;b&quot; ? &quot;banana&quot;
 : ($x == &quot;c&quot; ? &quot;carrot&quot;
 : &quot;default&quot;)));
</code></pre>
I know that probably makes a lot of people cringe, though.
One thing to keep in mind when using it in PHP is how it works with a function that returns a reference.
<pre><code>class Foo {
 var $bar;

 function Foo() {
 $this-&gt;bar = &quot;original value&quot;;
 }

 function &amp;tern() {
 return true ? $this-&gt;bar : false;
 }

 function &amp;notTern() {
 if (true) return $this-&gt;bar;
 else return false;
 }
}

$f = new Foo();
$b =&amp; $f-&gt;notTern();
$b = &quot;changed&quot;;
echo $f-&gt;bar; // &quot;changed&quot;

$f2 = new Foo();
$b2 =&amp; $f-&gt;tern();
$b2 = &quot;changed&quot;;
echo $f2-&gt;bar; // &quot;original value&quot;
</code></pre>

blocks|key|1732589|text|我最近看到了一个三元运算符的变体(好吧，某种程度上)，这使得标准的"()？:“变量看起来是清晰度的典范：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1732590|var+Result+=+[CaseIfFalse,+CaseIfTrue][(boolean+expression)]|code-block|syntax|javascript|1732591|或者，举一个更具体的例子：|1732592|var+Name+=+['Jane',+'John'][Gender+==+'m'];|1732593|注意，这是JavaScript，所以这样的事情在其他语言中可能是不可能的(谢天谢地)。|1732594|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Q|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|S|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

I recently saw a variation on ternary operators (well, sort of) that make the standard &quot;() ? :&quot; variant seem to be a paragon of clarity:
<pre><code>var Result = [CaseIfFalse, CaseIfTrue][(boolean expression)]
</code></pre>
or, to give a more tangible example:
<pre><code>var Name = ['Jane', 'John'][Gender == 'm'];
</code></pre>
Mind you, this is JavaScript, so things like that might not be possible in other languages (thankfully).

blocks|key|1517604|text|仅在以下情况下：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1517605|$var+=+(simple+>+test+?+simple_result_1+:+simple_result_2);|code-block|syntax|javascript|1517606|KISS。|offset|length|1517607|entityMap|0|LINK|mutability|MUTABLE|url|https://en.wikipedia.org/wiki/KISS_principle#In_software_development^0|0|0|0|4|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|T|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|U|8|@]|9|@$I|V|J|W|1|X]]|A|$]]|$1|K|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|L|$M|$5|N|O|P|A|$Q|R]]]]

Only when:
<pre><code>$var = (simple &gt; test ? simple_result_1 : simple_result_2);
</code></pre>
<a href="https://en.wikipedia.org/wiki/KISS_principle#In_software_development" rel="nofollow noreferrer">KISS</a>.

blocks|key|1732715|text|没有三元运算符，怎么会有人赢得混淆代码竞赛呢？！|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1732716|我个人赞成在适当的时候使用它，但我不认为我会嵌套它。它非常有用，但它有几个缺点，因为它使代码更难阅读，并在其他语言的其他操作中使用(如Groovy的null-check)。|offset|length|1732717|entityMap|0|LINK|mutability|MUTABLE|url|https://en.wikipedia.org/wiki/Groovy_%2528programming_language%2529^0|0|1V|6|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

How would anyone win an obfuscated code contest without the ternary operator?!
I'm personally for using it, when appropriate, but I don't think I'd ever nest it. It's very useful, but it has a couple knocks against it in that it makes code harder to read and is in use in some other languages in other operations (like <a href="https://en.wikipedia.org/wiki/Groovy_%28programming_language%29" rel="nofollow noreferrer">Groovy</a>'s null-check).

blocks|key|1517733|text|我通常在下面这样的事情中使用它：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1517734|before:

if(isheader)
++++drawtext(x,+y,+WHITE,+string);
else
++++drawtext(x,+y,+BLUE,+string);

after:

++++drawtext(x,+y,+isheader+==+true+?+WHITE+:+BLUE,+string);|code-block|syntax|javascript|1517735|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

I typically use it in things like this:
<pre><code>before:

if(isheader)
 drawtext(x, y, WHITE, string);
else
 drawtext(x, y, BLUE, string);

after:

 drawtext(x, y, isheader == true ? WHITE : BLUE, string);
</code></pre>

blocks|key|1517779|text|我喜欢Groovy的三元运算符的特殊情况，称为Elvis运算符：?：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1517780|expr+?:+default|code-block|syntax|javascript|1517781|如果不为空，则此代码的计算结果为expr，如果为空，则计算为default。从技术上讲，它不是真正的三元运算符，但它肯定与它相关，并且节省了大量的时间/输入。|1517782|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

I like Groovy's special case of the ternary operator, called the Elvis operator: ?:

<pre><code>expr ?: default
</code></pre>

This code evaluates to expr if it's not null, and default if it is. Technically it's not really a ternary operator, but it's definitely related to it and saves a lot of time/typing.

blocks|key|1517848|text|如果你的三元运算符最终获取了整个屏幕宽度，那么我就不会使用它。我只检查一个简单的条件并返回单个值：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1517849|int+x+=+something+==+somethingElse+?+0+:+-1;|code-block|syntax|javascript|1517850|在production...not+good中，我们实际上有一些像这样的讨厌代码：|1517851|int+x+=+something+==+(someValue+==+someOtherVal+?+string.Empty+:+"Blah+blah")+?+(a+==+b+?+1+:+2+):+(c+==+d+?+3+:+4);|1517852|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

If your ternary operator ends up taking the whole screen width, then I wouldn't use it. I keep it to just checking one simple condition and returning single values:
<pre><code>int x = something == somethingElse ? 0 : -1;
</code></pre>
We actually have some nasty code like this in production...not good:
<pre><code>int x = something == (someValue == someOtherVal ? string.Empty : &quot;Blah blah&quot;) ? (a == b ? 1 : 2 ): (c == d ? 3 : 4);
</code></pre>

blocks|key|1732947|text|三进制运算符对于简洁地生成逗号分隔的列表非常有用。下面是一个Java示例：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1732948|++++int[]+iArr+=+{1,+2,+3};
++++StringBuilder+sb+=+new+StringBuilder();
++++for+(int+i+=+0;+i+<+iArr.length;+i%2B%2B)+{
++++++++sb.append(i+==+0+?+iArr[i]+:+",+"+%2B+iArr[i]);
++++}
++++System.out.println(sb.toString());|code-block|syntax|javascript|1732949|它产生："1，2，3“|1732950|否则，最后一个逗号的特殊大小写将变得令人讨厌。|1732951|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

The ternary operator is extremely useful for concisely producing comma separated lists. Here is a Java example:
<pre><code> int[] iArr = {1, 2, 3};
 StringBuilder sb = new StringBuilder();
 for (int i = 0; i &lt; iArr.length; i++) {
 sb.append(i == 0 ? iArr[i] : &quot;, &quot; + iArr[i]);
 }
 System.out.println(sb.toString());
</code></pre>
It produces: &quot;1, 2, 3&quot;
Otherwise, special casing for the last comma becomes annoying.

blocks|key|1733011|text|如果你想减少代码中的行数或者重构代码，那么就去做吧。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1733012|如果你关心的是下一个程序员需要花费额外的0.1毫秒来理解表达式，那么无论如何都要去尝试。|1733013|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

If you are trying to reduce the amount of lines in your code or are refactoring code, then go for it.
If you care about the next programmer that has to take that extra 0.1 millisecond to understand the expression, then go for it anyway.

blocks|key|1733077|text|我喜欢它们，尤其是在类型安全的语言中。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1733078|我不明白这是怎么回事：|1733079|int+count+=+(condition)+?+1+:+0;|code-block|syntax|javascript|1733080|比这更难的是：|1733081|int+count;

if+(condition)
{
++count+=+1;
}
else
{
++count+=+0;
}|1733082|我会争辩说，三元运算符使一切都比另一种方式更简单和整洁。|1733083|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|S|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|T|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|U|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|V|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

I love them, especially in type-safe languages.
I don't see how this:
<pre><code>int count = (condition) ? 1 : 0;
</code></pre>
is any harder than this:
<pre><code>int count;

if (condition)
{
 count = 1;
}
else
{
 count = 0;
}
</code></pre>
I'd argue that ternary operators make everything less complex and more neat than the alternative.

blocks|key|1518134|text|对于简单的任务，比如根据条件分配不同的值，它们非常棒。我不会在有更长的表达式时使用它们，这取决于条件。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1518135|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

For simple tasks, like assigning a different value depending on a condition, they're great. I wouldn't use them when there are longer expressions depending on the condition though.

blocks|key|1733161|text|如果你和你的同事知道他们在做什么，而且他们不是在庞大的团队中创建的，我认为他们会让代码变得更简单，更容易阅读，因为代码更少。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1733162|我认为唯一一次三元运算符使代码更难理解是当你在一行中有超过三个或更多的代码时。大多数人不记得它们是基于优先级的，当你有一堆它们时，阅读代码就像噩梦一样。|1733163|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

If you and your workmates understand what they do and they aren't created in massive groups I think they make the code less complex and easier to read because there is simply less code.
The only time I think ternary operators make code harder to understand is when you have more than three or foyr in one line. Most people don't remember that they are right based precedence and when you have a stack of them it makes reading the code a nightmare.

blocks|key|1518262|text|我曾经属于“三元运算符使一行不可读”阵营，但在过去的几年里，当我适度使用它们时，我已经变得喜欢它们了。如果团队中的每个人都理解发生了什么，那么单行三元操作符可以增加可读性。这是一种简洁的方式，不需要为了花括号而花费大量的花括号。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1518263|我不喜欢它们的两种情况:如果它们超出了120列的范围，或者如果它们嵌入到其他三元运算符中。如果你不能快速，容易和可读性地表达你在三元运算符中所做的事情。然后使用if/else等效项。|1518264|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I used to be in the “ternary operators make a line un-readable” camp, but in the last few years I’ve grown to like them when used in moderation. Single line ternary operators can increase readability if everybody on your team understands what’s going on. It’s a concise way of doing something without the overhead of lots of curly braces for the sake of curly braces. 

The two cases where I don’t like them: if they go too far beyond the 120 column mark or if they are embedded in other ternary operators. If you can’t quickly, easily and readably express what you’re doing in a ternary operator. Then use the if/else equivalent.

blocks|key|1733286|text|这取决于:)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1733287|它们在处理可能为空的引用时非常有用(顺便说一句:+Java确实需要一种方法来比较两个可能为空的字符串)。|1733288|当您在一个表达式中嵌套多个三元运算符时，问题就开始了。|1733289|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

It depends :)
They are useful when dealing with possibly null references (BTW: Java really needs a way to easily compare two possibly null strings).
The problem begins, when you are nesting many ternary operators in one expression.

blocks|key|1733340|text|没有(除非它们被误用了)。当表达式是较大表达式的一部分时，三元运算符的使用通常要清晰得多。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1733341|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

No (unless they're misused). Where the expression is part of a larger expression, the use of a ternary operator is often much clearer.

blocks|key|1518389|text|我喜欢他们。我不知道为什么，但当我使用三元表达式时，我感觉非常酷。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1518390|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I like them. I don't know why, but I feel very cool when I use the ternary expression.

blocks|key|1518436|text|我见过这样的野兽(实际上要糟糕得多，因为它是isValidDate，而且还检查了每个月和每天，但我不想费心去记住整个事情)：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1518437|isLeapYear+=
++++((yyyy+%25+400)+==+0)
++++?+1
++++:+((yyyy+%25+100)+==+0)
++++++++?+0
++++++++:+((yyyy+%25+4)+==+0)
++++++++++++?+1
++++++++++++:+0;|code-block|syntax|javascript|1518438|显然，一系列if语句会更好(尽管这一条语句仍然比我见过的宏版本更好)。|1518439|我不介意像这样的小事情：|1518440|reportedAge+=+(isFemale+&&+(Age+>=+21))+?+21+%2B+(Age+-+21)+/+3+:+Age;|1518441|或者甚至是一些微妙的事情，比如：|1518442|printf+("Deleted+%25d+file%25s\n",+n,+(n+==+1)+?+""+:+"s");|1518443|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|T|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|U|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|V|8|@]|9|@]|A|$]]|$1|K|3|L|5|D|7|W|8|@]|9|@]|A|$E|F]]|$1|M|3|N|5|6|7|X|8|@]|9|@]|A|$]]|$1|O|3|P|5|D|7|Y|8|@]|9|@]|A|$E|F]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

I've seen such beasts like (it was actually much worse since it was isValidDate and checked month and day as well, but I couldn't be bothered trying to remember the whole thing):

<pre><code>isLeapYear =
 ((yyyy % 400) == 0)
 ? 1
 : ((yyyy % 100) == 0)
 ? 0
 : ((yyyy % 4) == 0)
 ? 1
 : 0;
</code></pre>

where, plainly, a series of if-statements would have been better (although this one's still better than the macro version I once saw).

I don't mind it for small things like:

<pre><code>reportedAge = (isFemale &amp;&amp; (Age &gt;= 21)) ? 21 + (Age - 21) / 3 : Age;
</code></pre>

or even slightly tricky things like:

<pre><code>printf ("Deleted %d file%s\n", n, (n == 1) ? "" : "s");
</code></pre>

blocks|key|1733472|text|我认为这真的取决于使用它们的上下文。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1733473|像这样的东西将是一种非常令人困惑的使用它们的方式，尽管有效：|1733474|+__CRT_INLINE+int+__cdecl+getchar+(void)
{
+++return+(--stdin->_cnt+>=+0)
++++++++++?++(int)+(unsigned+char)+*stdin->_ptr%2B%2B
++++++++++:+_filbuf+(stdin);
}|code-block|syntax|javascript|1733475|但是，这是：|1733476|c+=+a+>+b+?+a+:+b;|1733477|是完全合理的。|1733478|我个人认为，当它们减少过于冗长的IF语句时，应该使用它们。问题是，人们要么被它们吓坏了，要么太喜欢它们了，以至于几乎只使用它们而不是IF语句。|1733479|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|U|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|V|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|W|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|X|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|Y|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

I think it really depends on the context they are used in.

Something like this would be a really confusing, albeit effective, way to use them:

<pre><code> __CRT_INLINE int __cdecl getchar (void)
{
 return (--stdin-&gt;_cnt &gt;= 0)
 ? (int) (unsigned char) *stdin-&gt;_ptr++
 : _filbuf (stdin);
}
</code></pre>

However, this:

<pre><code>c = a &gt; b ? a : b;
</code></pre>

is perfectly reasonable.

I personally think they should be used when they cut down on overly verbose IF statements. The problem is people are either petrified of them, or like them so much they get used almost exclusively instead of IF statements.

blocks|key|1733508|text|如果您使用三元运算符进行简单的条件赋值，我认为这是很好的。我见过它(Ab)用于控制程序流，甚至不进行赋值，我认为应该避免这种情况。在这些情况下，请使用if语句。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1733509|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

If you're using the ternary operator for a simple conditional assignment I think it's fine. I've seen it (ab)used to control program flow without even making an assignment, and I think that should be avoided. Use an if statement in these cases.

blocks|key|1733545|text|不是的。它们很难读懂。If/Else更容易阅读。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1733546|这是我的观点。Your+mileage+may+vary。|offset|length|1733547|entityMap|0|LINK|mutability|MUTABLE|url|https://en.wiktionary.org/wiki/your_mileage_may_vary#Phrase^0|0|7|L|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

No. They are hard to read. If/Else is much easier to read.
This is my opinion. <a href="https://en.wiktionary.org/wiki/your_mileage_may_vary#Phrase" rel="nofollow noreferrer">Your mileage may vary</a>.

blocks|key|1733591|text|string+someSay+=+bCanReadThis？"No“：”是“；|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1733592|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

string someSay = bCanReadThis ? "No" : "Yes";

blocks|key|1733666|text|在很小的剂量下，它们可以减少行数并使代码更具可读性；特别是当结果类似于根据计算结果将字符字符串设置为"Yes“或"No”时。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1733667|示例：|1733668|char*+c+=+NULL;
if(x)+{
++c+=+"true";
}else+{
++c+=+"false";
}|code-block|syntax|javascript|1733669|对比：|1733670|char*+c+=+x+?+"Yes"+:+"No";|1733671|在这样的简单测试中，唯一可能出现的错误是赋值不正确，但由于条件通常很简单，程序员出错的可能性较小。让你的程序打印出错误的输出并不是世界末日，应该在所有的代码审查、工作台测试和生产测试阶段都能捕捉到。|1733672|我将反驳我自己的论点，现在使用代码覆盖率度量来帮助了解您的测试用例有多好变得更加困难。在第一个示例中，您可以在两个赋值行上测试复盖率；如果没有复盖一个，那么您的测试没有执行所有可能的代码流。|1733673|在第二个示例中，无论X的值是多少，该行都将显示为正在执行，因此您不能确定您已经测试了备用路径(YMMV取决于您的覆盖工具的能力)。|offset|length|1733674|随着测试的日益复杂，这一点变得更加重要。|1733675|entityMap|0|LINK|mutability|MUTABLE|url|https://en.wiktionary.org/wiki/YMMV^0|0|0|0|0|0|0|0|1B|4|0|0|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|15|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|16|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|17|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|18|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|19|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|1A|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1B|8|@]|9|@$S|1C|T|1D|1|1E]]|A|$]]|$1|U|3|V|5|6|7|1F|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1G|8|@]|9|@]|A|$]]]|X|$Y|$5|Z|10|11|A|$12|13]]]]

In small doses they can reduce the number of lines and make code more readable; particularly if the outcome is something like setting a char string to &quot;Yes&quot; or &quot;No&quot; based on the result of a calculation.
Example:
<pre><code>char* c = NULL;
if(x) {
 c = &quot;true&quot;;
}else {
 c = &quot;false&quot;;
}
</code></pre>
compared with:
<pre><code>char* c = x ? &quot;Yes&quot; : &quot;No&quot;;
</code></pre>
The only bug that can occur in simple tests like that is assigning an incorrect value, but since the conditional is usually simple it's less likely the programmer will get it wrong. Having your program print the wrong output isn't the end of the world, and should be caught in all of code review, bench testing and production testing phases.
I'll counter my own argument with now it's more difficult to use code coverage metrics to assist in knowing how good your test cases are. In the first example you can test for coverage on both the assignment lines; if one is not covered then your tests are not exercising all possible code flows.
In the second example the line will show as being executed regardless of the value of X, so you can't be certain you've tested the alternate path (<a href="https://en.wiktionary.org/wiki/YMMV" rel="nofollow noreferrer">YMMV</a> depending on the ability of your coverage tools).
This matters more with the increasing complexity of the tests.

blocks|key|1518768|text|似乎没有人提到使用三元运算符的一个原因，即支持类型推断的三元运算符，至少在D等语言中是这样的，这是为了允许类型推断对极其复杂的模板类型起作用。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1518769|auto+myVariable+=+fun();
//+typeof(myVariable)+==+Foo!(Bar,+Baz,+Waldo!(Stuff,+OtherStuff)).

//+Now+I+want+to+declare+a+variable+and+assign+a+value+depending+on+some
//+conditional+to+it.
auto+myOtherVariable+=+(someCondition)+?+fun()+:+gun();

//+If+I+didn't+use+the+ternary+I'd+have+to+do:
Foo!(Bar,+Baz,+Waldo!(Stuff,+OtherStuff))+myLastVariable;++//+Ugly.
if(someCondition)+{
++++myLastVariable+=+fun();
}+else+{
++++myLastVariable+=+gun():
}|code-block|syntax|javascript|1518770|entityMap|0|LINK|mutability|MUTABLE|url|https://en.wikipedia.org/wiki/D_(programming_language))^0|11|1|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@$A|R|B|S|1|T]]|C|$]]|$1|D|3|E|5|F|7|U|8|@]|9|@]|C|$G|H]]|$1|I|3|-4|5|6|7|V|8|@]|9|@]|C|$]]]|J|$K|$5|L|M|N|C|$O|P]]]]

One reason no one seems to mention for using the ternary operator, at least in languages, like <a href="https://en.wikipedia.org/wiki/D_(programming_language)" rel="nofollow noreferrer">D</a>, that support type inference is to allow type inference to work for amazingly complicated template types.
<pre><code>auto myVariable = fun();
// typeof(myVariable) == Foo!(Bar, Baz, Waldo!(Stuff, OtherStuff)).

// Now I want to declare a variable and assign a value depending on some
// conditional to it.
auto myOtherVariable = (someCondition) ? fun() : gun();

// If I didn't use the ternary I'd have to do:
Foo!(Bar, Baz, Waldo!(Stuff, OtherStuff)) myLastVariable; // Ugly.
if(someCondition) {
 myLastVariable = fun();
} else {
 myLastVariable = gun():
}
</code></pre>

blocks|key|1518890|text|我喜欢运算符在某些情况下，但我认为有些人倾向于过度使用它，它会使代码更难阅读。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1518891|我最近在一些我正在努力修改的开源代码中偶然发现了这一行。|1518892|哪里|1518893|++++(active+==+null+?+true+:
++++((bool)active+?+p.active+:+!p.active))+&&...|code-block|syntax|javascript|1518894|而不是|1518895|where+(+active+==+null+%7C%7C+p.active+==+active)+&&...|1518896|我想知道在这种情况下，三元使用是否会给LINQ语句增加额外的开销。|offset|length|1518897|entityMap|0|LINK|mutability|MUTABLE|url|https://en.wikipedia.org/wiki/Language_Integrated_Query^0|0|0|0|0|0|0|J|4|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|11|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|12|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|13|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|14|8|@]|9|@]|A|$]]|$1|M|3|N|5|H|7|15|8|@]|9|@]|A|$I|J]]|$1|O|3|P|5|6|7|16|8|@]|9|@$Q|17|R|18|1|19]]|A|$]]|$1|S|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]]|T|$U|$5|V|W|X|A|$Y|Z]]]]

I like the operator in some situations, but I think some people tend to overuse it and that it can make the code harder to read.
I recently stumbled across this line in some open source code I am working to modify.
Where
<pre><code> (active == null ? true :
 ((bool)active ? p.active : !p.active)) &amp;&amp;...
</code></pre>
Instead of
<pre><code>where ( active == null || p.active == active) &amp;&amp;...
</code></pre>
I wonder if the ternary use adds extra overhead to the <a href="https://en.wikipedia.org/wiki/Language_Integrated_Query" rel="nofollow noreferrer">LINQ</a> statement in this case.

blocks|key|1733965|text|我同意这里许多海报的观点。三元运算符是完全有效的，只要它被正确使用，并且不会引入歧义(公平地说，您可以这样说任何运算符/构造)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1733966|我经常在嵌入式代码中使用三元运算符来阐明我的代码在做什么。请使用以下代码示例(为清晰起见，过于简化)：|1733967|代码片段1：|1733968|int+direction+=+read_or_write(io_command);

//+Send+an+I/O
io_command.size+=+(direction==WRITE)+?+(32+*+1024)+:+(128+*+1024);
io_command.data+=+&buffer;
dispatch_request(io_command);|code-block|syntax|javascript|1733969|代码片段2：|1733970|int+direction+=+read_or_write(io_command);

//+Send+an+I/O
if+(direction+==+WRITE)+{
++++io_command.size+=+(32+*+1024);
++++io_command.data+=+&buffer;
++++dispatch_request(io_command);
}+else+{
++++io_command.size+=+(128+*+1024);
++++io_command.data+=+&buffer;
++++dispatch_request(io_command);
}|1733971|这里，我正在分派一个输入或输出请求。无论请求是读取还是写入，该过程都是相同的，只是默认I/O大小发生了变化。在第一个示例中，我使用三进制运算符来表明过程是相同的，并且size字段根据I/O方向获得不同的值。在第二个示例中，对于这两种情况的算法是否相同并不是很清楚(特别是当代码增长的长度远远超过三行时)。第二个示例将更难保持公共代码同步。在这里，三元运算符更好地表达了代码的大部分并行性。|offset|length|style|CODE|1733972|三元运算符还有另一个优点(尽管这通常只是嵌入式软件的一个问题)。一些编译器只能在代码未“嵌套”超过一定深度时才能执行某些优化(即在函数内部，每次输入if、loop或switch语句时，嵌套深度增加1，当离开语句时，嵌套深度减少1)。有时，使用三元运算符可以最小化条件中需要的代码量(有时达到编译器可以优化条件的程度)，并可以减少代码的嵌套深度。在某些情况下，我能够使用三元运算符(如上面的示例)重新构造一些逻辑，并将函数的嵌套深度降低到足以使编译器能够对其执行额外的优化步骤。诚然，这是一个相当狭窄的用例，但我认为无论如何都值得一提。|1733973|entityMap^0|0|0|0|0|0|0|2B|4|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Z|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|10|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|11|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|12|8|@]|9|@]|A|$]]|$1|M|3|N|5|H|7|13|8|@]|9|@]|A|$I|J]]|$1|O|3|P|5|6|7|14|8|@$Q|15|R|16|S|T]]|9|@]|A|$]]|$1|U|3|V|5|6|7|17|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|18|8|@]|9|@]|A|$]]]|X|$]]

I agree with the sentiments of many of the posters here. The ternary operator is perfectly valid as long as it is used correctly and does not introduce ambiguity (to be fair, you can say that about any operator/construct).

I use the ternary operator often in embedded code to clarify what my code is doing. Take the following (oversimplified for clarity) code samples:

Snippet 1:

<pre><code>int direction = read_or_write(io_command);

// Send an I/O
io_command.size = (direction==WRITE) ? (32 * 1024) : (128 * 1024);
io_command.data = &amp;buffer;
dispatch_request(io_command);
</code></pre>

Snippet 2:

<pre><code>int direction = read_or_write(io_command);

// Send an I/O
if (direction == WRITE) {
 io_command.size = (32 * 1024);
 io_command.data = &amp;buffer;
 dispatch_request(io_command);
} else {
 io_command.size = (128 * 1024);
 io_command.data = &amp;buffer;
 dispatch_request(io_command);
}
</code></pre>

Here, I am dispatching an input or output request. The process is the same whether the request is a read or a write, only the default I/O size changes. In the first sample, I use the ternary operator to make it clear that the procedure is the same and that the <code>size</code> field gets a different value depending on the I/O direction. In the second example, it is not as immediately clear that the algorithm for the two cases is the same (especially as the code grows much longer than three lines). The second example would be more difficult to keep the common code in sync. Here, the ternary operator does a better job of expressing the largely parallel nature of the code.

The ternary operator has another advantage (albeit one that is normally only an issue with embedded software). Some compilers can only perform certain optimizations if the code is not "nested" past a certain depth (meaning inside a function, you increase the nesting depth by 1 every time you enter an if, loop, or switch statement and decrease it by 1 when you leave it). On occasion, using the ternary operator can minimize the amount of code that needs to be inside a conditional (sometimes to the point where the compiler can optimize away the conditional) and can reduce the nesting depth of your code. In some instances, I was able to re-structure some logic using the ternary operator (as in my example above) and reduce the nested depth of the function enough that the compiler could perform additional optimization steps on it. Admittedly this is a rather narrow use case, but I figured it was worth mentioning anyway.

blocks|key|1519053|text|三元运算符不在话下。如果格式正确，它们并不复杂。以闰年为例from+paxdiablo|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1519054|$isLeapYear+=
+++(($year+%25+400)+==+0)
+++?+1
+++:+((($year+%25+100)+==+0)
++++++?+0
++++++:+((($year+%25+4)+==+0)
+++++++++?+1
+++++++++:+0));|code-block|syntax|javascript|1519055|这可以写得更简洁，并通过以下格式使其更具可读性：|1519056|//--------------Test+expression-----Result
$isLeapYear+=+(($year+%25+400)+==+0)+?+1+:
++++++++++++++((($year+%25+100)+==+0)?+0+:
++++++++++++++((($year+%25+4)+==+0)++?+1+:
+++++++++++++++++++++++++++++++++++++0));+//+Default+result|1519057|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/160218/to-ternary-or-not-to-ternary/535124#535124^0|T|E|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@$A|V|B|W|1|X]]|C|$]]|$1|D|3|E|5|F|7|Y|8|@]|9|@]|C|$G|H]]|$1|I|3|J|5|6|7|Z|8|@]|9|@]|C|$]]|$1|K|3|L|5|F|7|10|8|@]|9|@]|C|$G|H]]|$1|M|3|-4|5|6|7|11|8|@]|9|@]|C|$]]]|N|$O|$5|P|Q|R|C|$S|T]]]]

The ternary operator hands down. They aren't complex if you format properly. Take the leap year example <a href="https://stackoverflow.com/questions/160218/to-ternary-or-not-to-ternary/535124#535124">from paxdiablo</a>:
<pre><code>$isLeapYear =
 (($year % 400) == 0)
 ? 1
 : ((($year % 100) == 0)
 ? 0
 : ((($year % 4) == 0)
 ? 1
 : 0));
</code></pre>
This can be written more concise and be made much more readable with this formatting:
<pre><code>//--------------Test expression-----Result
$isLeapYear = (($year % 400) == 0) ? 1 :
 ((($year % 100) == 0)? 0 :
 ((($year % 4) == 0) ? 1 :
 0)); // Default result
</code></pre>

blocks|key|1734060|text|(当天的黑客攻击)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1734061|#define+IF(x)+x+?
#define+ELSE+:|code-block|syntax|javascript|1734062|然后，您可以将if-+Then+-else作为表达式：|1734063|int+b+=+IF(condition1)++++res1
++++++++ELSE+IF(condition2)++res2
++++++++ELSE+IF(conditions3)+res3
++++++++ELSE+res4;|1734064|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

(Hack of the day)

<pre><code>#define IF(x) x ?
#define ELSE :
</code></pre>

Then you can do if-then-else as expression:

<pre><code>int b = IF(condition1) res1
 ELSE IF(condition2) res2
 ELSE IF(conditions3) res3
 ELSE res4;
</code></pre>

blocks|key|1519163|text|使代码变得更小并不总是意味着更容易解析。它在不同的语言中是不同的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1519164|例如，在PHP中，鼓励使用空格和换行符，因为PHP的lexer首先将代码分成几位，从换行符开始，然后是空格。所以我看不到性能问题，除非使用更少的空格。|offset|length|1519165|不好：|1519166|($var)?1:0;|code-block|syntax|javascript|1519167|好：|1519168|($var)+?+1+:+0;|1519169|这似乎不是什么大问题，但是对于PHP中的词法分析代码，空格是必不可少的。另外，这样读起来也会更好一些。|1519170|entityMap|0|LINK|mutability|MUTABLE|url|https://en.wikipedia.org/wiki/PHP^0|0|4|3|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|11|8|@]|9|@$D|12|E|13|1|14]]|A|$]]|$1|F|3|G|5|6|7|15|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|16|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|17|8|@]|9|@]|A|$]]|$1|O|3|P|5|J|7|18|8|@]|9|@]|A|$K|L]]|$1|Q|3|R|5|6|7|19|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]]|T|$U|$5|V|W|X|A|$Y|Z]]]]

Making code smaller doesn't always mean it's easier to parse. It differs from language to language.
In <a href="https://en.wikipedia.org/wiki/PHP" rel="nofollow noreferrer">PHP</a> for example, whitespace and line-breaks are encouraged since PHP's lexer first breaks the code up in bits starting with line-breaks and then whitespace. So I do not see a performance issue, unless less whitespace is used.
Bad:
<pre><code>($var)?1:0;
</code></pre>
Good:
<pre><code>($var) ? 1 : 0;
</code></pre>
It doesn't seem like a big issue, but with lexing code in PHP, whitespace is essential. Plus, it also reads a bit better this way.

I'm personally an advocate of the ternary operator: () ? : ; I do realize that it has its place, but I have come across many programmers that are completely against ever using it, and some that use it too often.

What are your feelings on it? What interesting code have you seen using it?

To ternary or not to ternary?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我个人是三元运算符的倡导者：()？：；我确实意识到它有它的位置，但我遇到了许多程序员，他们完全反对使用它，有些人使用它太频繁了。你对此有何感想？您在使用它时看到了哪些有趣的代码？

问三进制还是不三进制？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问三进制还是不三进制？EN