本问题已经有最佳答案，请猛点这里访问。
我容易出现"如果条件综合症"，这意味着我倾向于一直使用if条件。 我很少使用三元运算符。 例如：
//I like to do this:
int a;
if (i == 0)
{
a = 10;
}
else
{
a = 5;
}
//When I could do this:
int a = (i == 0) ? 10:5;
我使用哪个有关系吗？ 哪个更快？ 是否有明显的性能差异？ 尽可能使用最短的代码是更好的做法吗？
没关系，您应该更关注干净的代码而不是性能。在这种情况下，我认为三元运算符更干净。
另外，您可以像这样if(i == 0) a = 10; else a = 5;
不进行概要分析就显示明确需求的过早优化是不好的，不好的，不好的。使用您的未来自己将在6个月后最能理解的代码。
我同意@Niklas，但是如果您真的不喜欢三元运算符，并且您不关心真正的琐碎的性能差异，则可以将变量初始化为默认值(大概为5)，并且仅使用" if"而不使用" else"重新分配它。
@Hovercraft：您自己和您的同事，很想在这里添加。
在少数情况下，三元运算符会编译为没有分支的代码序列。但是在大多数情况下，没有性能差异(或者如果存在，则可以忽略不计)。使用最容易理解的内容以及使程序逻辑更清晰的内容。
恕我直言，三元运算符太可怕了！
Does it matter which I use?
是!第二个更具可读性。您正在交易一条线，用九行有效的杂乱简洁地表达您想要的内容。
Which is faster?
都不是。
Is it a better practice to use the shortest code whenever possible?
不是"只要有可能"，而是肯定只要有可能而不会造成不利影响。较短的代码至少可能更具可读性，因为它专注于相关部分而不是附带影响("样板代码")。
易读，并不意味着它重要。
如果我算对的话，甚至9行，因为那里也有太多的空白。
@Jon：是的，确实如此。可读性是有效的一切。
@Jon如果唯一的区别是可读性，那么可读性就是一切。
好了，在我提供的示例中，使用三元会更明智。
如果您可以使用较短的方法避免使用临时变量，则在内存消耗和执行时间上会有所不同。
@ xdevs23您能解释一下这个意思吗，最好举个例子吗？因为我了解您的方式绝对是错误的。
int blabla = someStaticNumber; if(blabla < 3) blabla += 3; return blabla;。相反，您可以这样做：return someStaticNumber < 3 ? someStaticNumber + 3 : someStaticNumber;
@ xdevs23(1)这些不是等效的；您不需要带if语句的临时变量，并且如果将其删除，则这两种选择是相同的。 (2)我不特别了解Java，但通常来说，任何不错的编译器都会为您的两个不相同的语句生成相同的机器代码。 —因此，不，使用if语句和条件运算符之间没有区别。
好吧，我不确定编译器是否真的摆脱了临时变量……这是一个非常糟糕的例子。大声笑
我想补充一点，三元并不总是更具可读性。考虑maxSpeed = isParkingLot() ? 5 : ( isInnerCity() ? 50 : 100);与if链或switch语句的对比。另外，当表达式变长(maxSpeed = map.getStreetType(car.getLocation()) == MapType.PARKING_LOT ? TrafficRules.getMaxSpeed(MapType.PARKING_LOT) : TrafficRules.getMaxSpeed())时，可能很难读取。
@Giszmo但是if在任何情况下都不容易阅读。长条件可以与临时变量分开。可以通过跨行中断链接的条件语句来使其变得可读。这是一种非常完善的模式，是根据多种编程语言中的条件进行分派的惯用方式。
可读性是主观的。可以达成普遍共识，但没有个别协议。因此，在这里辩论是没有意义的。
如果有任何性能差异(我怀疑)，则可以忽略不计。专注于编写最简单，最易读的代码。
话虽如此，请尝试克服对条件运算符的厌恶-尽管当然有可能过度使用它，但在某些情况下它确实很有用。在您提供的特定示例中，我肯定会使用条件运算符。
为什么在这里使用条件式？我会用三元清洁。
@Jon：条件运算符是您所说的三元运算符的实际名称。它是一个三元运算符，因为它有3个操作数，但它的名称是条件运算符。
好的，谢谢您的澄清。我以为您是指显式if-else语法。
三元运算符示例：
int a = (i == 0) ? 10 : 5;
您不能使用if / else这样进行分配：
// invalid:
int a = if (i == 0) 10; else 5;
这是使用三元运算符的一个很好的理由。如果您没有作业：
(i == 0) ? foo () : bar ();
if / else没那么多代码：
if (i == 0) foo (); else bar ();
在性能至关重要的情况下：进行测量。如果存在瓶颈，请使用目标计算机，目标JVM和典型数据进行测量。否则会增加可读性。
嵌入上下文中，简短形式有时非常方便：
System.out.println ("Good morning" + (p.female ?"Miss" :"Mister") + p.getName ());
使用三元运算符还有另一个原因-它使您能够处理所有情况。
@MikeDunlavey：如果想到哦，别忘了第二种情况！让我们使用三元运算符，也可以开始编写其他操作，不要忘记它，如果您的大脑非常不可靠，则可以在编写语句的几秒钟内忘记它。
这不仅是编写" else"的问题，还包括您输入的内容。
@MikeDunlavey：我以为你的主张是，使用？ ：应该有助于避免忘记其他部分，这会引发问题，怎么办？ ：应避免忘记它。也许是因为在大多数情况下，如果没有它，生成的代码将不正确，从而引发编译器错误？好了，可以先编写else-keyword来存档。区别在哪里？
是的，这很重要，但不是因为代码执行性能。
与简单的语法构造相比，更快的(性能)编码与循环和对象实例化更相关。编译器应该进行优化(所有代码都是相同的二进制文件！)，因此您的目标应该是"从头到尾"的效率(人永远是软件的瓶颈)。
Josh Bloch在上的"性能焦虑"演讲
引用9行而不是1行的答案可能会误导您：更少的代码行并不总是等于更好。
在有限的情况下，三元运算符可能是一种更简洁的方法(您的例子就是一个很好的例子)。
但是它们经常被滥用以使代码不可读(这是一个主要的罪过)=不要嵌套三元运算符！
还请考虑将来的可维护性，if-else易于扩展或修改：
int a;
if ( i != 0 && k == 7 ){
a = 10;
logger.debug("debug message here" );
}else
a = 3;
logger.debug("other debug message here" );
}
int a = (i != 0 && k== 7 ) ? 10 : 3; // density without logging nor ability to use breakpoints
附：是非常完整的stackoverflow答案，是三元还是非三元？
我不同意这一点：例如，嵌套条件语句是惯用的且可读的，特别是在测试多个案例(如return x == 1 ?"one" : x == 2 ?"two" :"many";中)时。适当的缩进和分成多行在这里有帮助。
三元运算符只是简写。它们将编译为等效的if-else语句，这意味着它们将完全相同。
同样，三元运算符启用"可选"参数的形式。 Java不允许在方法签名中使用可选参数，但是当为参数值提供null时，三元运算符使您可以轻松地内联默认选项。
例如：
public void myMethod(int par1, String optionalPar2) {
String par2 = ((optionalPar2 == null) ? getDefaultString() : optionalPar2)
.trim()
.toUpperCase(getDefaultLocale());
}
在上面的示例中，将null作为参数String传递给您默认字符串值，而不是NullPointerException。它简短而有趣，我想说，它可读性强。而且，正如已经指出的，在字节码级别上，三元运算符和if-then-else之间确实没有区别。如以上示例所示，选择哪个选项的决定完全基于可读性。
此外，此模式使您可以通过重载以下方法使String参数真正可选(如果认为这样做有用)：
public void myMethod(int par1) {
return myMethod(par1, null);
}
对于给定的示例，由于特定原因，我更喜欢三元或条件运算符(?)：我可以清楚地看到分配a不是可选的。 通过一个简单的示例，扫描if-else块以查看在每个子句中分配了a并不是很困难，但是可以想象每个子句中有多个分配：
if (i == 0)
{
a = 10;
b = 6;
c = 3;
}
else
{
a = 5;
b = 4;
d = 1;
}
a = (i == 0) ? 10 : 5;
b = (i == 0) ? 6 : 4;
c = (i == 0) ? 3 : 9;
d = (i == 0) ? 12 : 1;
我更喜欢后者，这样您就知道您没有错过任何作业。
尝试使用switch case语句，但通常这不是性能瓶颈。
通常可以避免使用switch块的解决方案。就其性质而言，switch适用于固定数量的允许状态。由于"允许状态"通常是一个移动目标，因此产生了软件维护责任。例如，使用enum类的解决方案通常比基于switch块的解决方案更好，更优雅。
最好使用任何读起来更好的东西-实际效果之间，性能之间存在0差异。
在这种情况下，我认为最后一个语句比第一个if语句读起来更好，但要注意不要过度使用三元运算符-有时它确实会使事情变得不太清楚。
