依赖Java的短路评估（编码风格）[关闭]答案

【问题标题】：relying on Java's short-circuiting evaluation (coding style) [closed]依赖Java的短路评估（编码风格）[关闭]
【发布时间】：2014-05-16 15:34:29
【问题描述】：

在布尔评估中严重依赖短路是一种好的编码风格吗？

我认识一个喜欢这样做的人。例如，如果业务逻辑是“如果 Alice 不饿，或者如果 Alice 和 Bob 都饿了”，而不是写

// 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）时才计算右操作数。

（令人讨厌的是，乍一看，您会认为这是一个错误，但如果您将其更改为更明显的内容，您会觉得您看起来很愚蠢！）

【问题讨论】：

【解决方案1】：

您当然可以并且应该依赖表达式中的短路，但是您给出的示例只是糟糕的编程。表达式的逻辑应该与注释和测试的人类可读逻辑相匹配。优化器完全理解布尔逻辑，并将优化您的队友可能抱怨的任何明显的低效率。

最重要的是让代码对开发者来说清晰易懂。编写聪明的代码来证明自己的聪明绝非一个好习惯。

【讨论】：

【解决方案2】：

它曾经是一种好的风格吗？是的，我想大多数人都能欣赏这种惯用的风格：

myFoo != null && myFoo.myMethod();

【讨论】：

【解决方案3】：

这实际上与短路无关；即使没有短路，这两个表达式也是等价的：

A B !A | A & B !A |乙 ---------------------------------- 0 0 1 1 0 1 1 1 1 0 0 0 1 1 1 1

只要选择您认为将来更容易理解和管理的那个即可；以更明确的方式传达您的目的。这方面的明显赢家似乎是你的第一个 sn-p。

【讨论】：

【解决方案4】：

我认为在这种情况下，无论是否短路，结果都是一样的。他不是在这里依赖短路，而是在简化所需的逻辑。

在我看来，没有一个非常可靠的黑白答案。我个人不会像这样简化逻辑语句，因为对我来说，当我稍后再回到它时很难阅读。添加额外的逻辑来明确解释我的检查不会

【讨论】：

【解决方案5】：

在这种情况下，您实际上并没有“依赖”短路评估。您只是在简化布尔表达式。 & 和 && 的逻辑相同。

短路的影响是：

因此，短路不会以任何方式改变布尔结果。

【讨论】：