String word = ...;
if ("s".equals(word) || "y".equals(word))
Bill Pugh在Devoxx 2011上提出了这个问题。绝大多数人选择使用形式为"xyz".equals(str)的方式。我支持Bill，现在更喜欢str.equals("xyz")的方式。
Java传统中最基本的原则就是尽早发现错误。NullPointerException异常非常普遍。我们希望能够尽早排除这些空值。
如果你预计引用可能为null，那么我并不反对使用反向符号。明确指定有可能存在null，并在另外的null检查中更容易理解，但是反向顺序应该被充分理解，并且足以将代码与禁止出现null的普通情况区分开来。
在安全领域工作时，一些空值容错问题可能会导致漏洞。
将常量放在变量之前进行比较的Yoda条件可以被视为不良实践，因为它使代码行难以理解。然而，在这种特定情况下，我认为使用Yoda条件会使代码更易于理解，因为您不需要在其前面加上额外的null检查。
这取决于具体情况。如果在您的程序中，“word”永远不应该为null，则使用“word.equals（“s”）”可能更好。如果由于某种鲜为人知的原因“word”将变为null，则会出现NullPointerException。
仔细想一想，如果您得到异常，就知道出了问题，可以更快地发现错误并进行修复。如果程序在静默中继续运行并产生错误结果，则很难检测到问题。实际上，您可能根本没有注意到存在问题。
一切都要看具体情况。
你可以写
if (word != null && (word.equals("s") || word.equals("y")))
替代
if ("s".equals(word) || "y".equals(word))
word，这是很好甚至至关重要的信息。 - Ole V.V.有几个原因不建议这样做，但最终取决于你（或团队）是否认为这是糟糕的编码风格。反对它的论点包括：
正如我所说，我认为这些论点并不是非常强大，也没有理由像你这样做。因此，最重要的是就编码风格达成一致，并坚持下去。
TL;DR; 这绝对是不好的编码风格，而不是好的 :D
嗯，在非布尔类型可以评估为布尔值的语言中，尤达条件非常有用，例如
int test = 0;
if ( test ){ /* do something */
但在Java中不允许这样做，因此您不会遇到忘记'='等问题。
if ( test = 2 ){ /* do something */
使用 test == 2 的方式不被编译器所允许。因此，对于那些没有关注过这个问题的人来说，Yoda 表达式可能会显得不自然（因为他/她没有使用除 Java 以外的其他语言）。
if (test = true)，这当然是更糟糕的风格。 - Jörn Horstmann有一种特殊情况的 Yoda 条件语句我在任何答案中都没有看到过被辩护或攻击，所以我会加上它作为参考。这种风格是：
if(0 < x && x <= max) {
0）在变量（x）之前。反对 Yoda 条件语句的论点是它会影响可读性。将该示例与功能等效的示例进行对比。 if(x <= max && x > 0) {
你真的认为非 Yoda 变体更易读吗？我不这么认为。
在使用排序关系运算符（<，<=，>，>=）时，为了可读性，我更喜欢以下启发式方法的风格：
这往往会产生一个 Yoda 条件来表示下限。
x <= max && x > 0，而不是更正确的翻译 x > 0 && x <= max，因为你想要代替 Yoda 表达式而不是重新排列表达式。并且 Yoda 表达式仅有一个优点，那就是“0 < x < y”是一种常见的数学方式来描述边界（或“(0, y)”但那是另外一回事 :D）。 - TomYoda条件是指在变量前面放置文字。
word.equals("s") 读作“word equals s”
"s".equals(word) 人类读作“s equals word”
我们的大脑更容易理解第一个例子，代码也更清晰。
我个人认为使用Yoda条件的唯一原因是防止赋值，例如“if (42 = i)”而不是“if(42 == i)”。
if (i = 42)也是不被允许的，因为花括号之间必须是一个布尔表达式而i = 42不是一个布尔表达式。 - Jesper
null检查），因此辩论不可避免地陷入了风格、一致性、可读性等方面的比较。 - Jon