在布尔评估中严重依赖短路是否是一种良好的编码风格？
我认识一个喜欢这样做的人.例如,如果业务逻辑是"如果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)时,才对右操作数进行评估.
(令人烦恼的是,乍一看,你会认为这是一个错误,但如果你把它改成更明显的话,你会觉得你看起来很愚蠢!)
Rob*_*Rob 10
你当然可以而且应该依赖于表达式中的短路,但你给出的例子就是糟糕的编程.表达式的逻辑应该与注释和测试的人类可读逻辑相匹配.优化器完全理解布尔逻辑,并将优化您的队友可能抱怨的任何明显的低效率.
最重要的是为开发人员提供清晰易懂的代码.编写聪明的代码来证明你是多么聪明,这绝不是一个好习惯.
这是一种好风格吗？是的,我认为大多数人都会欣赏这种惯用的风格:
myFoo != null && myFoo.myMethod();
我想在这种情况下，无论短路与否，结果都是一样的。他在这里并不依赖短路，而是简化所需的逻辑。
在我看来，没有一个非常明确的黑白答案。我个人不会像这样简化逻辑语句，因为对我来说，当我稍后再回来时很难阅读。添加额外的逻辑来明确解释我的检查不会
| 归档时间： |
|
| 查看次数： |
247 次 |
| 最近记录： |