在布尔评估中严重依赖短路是否是一种好的编码风格？
我认识一个喜欢这样做的人。 例如，如果业务逻辑是＆＃34;如果Alice不饿，或者Alice和Bob都饿了＆＃34;而不是写
// if Alice is not hungry or both alice and bob are hungry
if (!A || A && B)`
他会写
// if Alice is not hungry OR both alice and bob are hungry
if (!A || B)
认为||是短路的，所以当且仅当第一个是false（意味着A = true）时才会评估右操作数。
（令人烦恼的是，乍一看，你会认为这是一个错误，但如果你把它改成更明显的话，你会觉得你看起来很愚蠢！）
答案 0 :(得分：10)
你当然可以而且应该依赖于表达式中的短路，但你给出的例子就是糟糕的编程。表达式的逻辑应该与注释和测试的人类可读逻辑相匹配。优化器完全理解布尔逻辑，并将优化你的队友可能抱怨的任何明显的低效率。
最重要的是为开发人员提供清晰易懂的代码。编写聪明的代码来证明你是多么聪明，这绝不是一个好习惯。
答案 1 :(得分：8)
这是一种好的风格吗？是的，我认为大多数人都会欣赏这种惯用的风格：
myFoo != null && myFoo.myMethod();
答案 2 :(得分：3)
这与短路没有任何关系;即使没有短路，这两个表达式也是等效的：
A B !A | A & B !A | B ----------------------------------- 0 0 1 1 0 1 1 1 1 0 0 0 1 1 1 1
选择您认为将来更容易理解和管理的任何一个;任何更明确地表达你的目的。在这方面明显的赢家似乎是你的第一个片段。
答案 3 :(得分：0)
我认为在这种情况下，无论是否短路，结果都是一样的。他不依赖于此处的短路，而是简化所需的逻辑。
在我看来，没有一个非常坚实的黑白答案。我个人不会简化这样的逻辑陈述，因为对我来说，当我稍后再回到它时很难读。添加额外的逻辑来明确解释我的检查不会
答案 4 :(得分：0)
在这种情况下，您实际上并非“依赖”短路评估。您只是简化了布尔表达式。该逻辑与&和&&的作用相同。
短路的影响是：
因此，短路不会以任何方式改变布尔结果。