我永远不明白为什么我们使用这样的语法:
if (a == b || a == c)
当它可以简化为这样的东西:
if (a == b || c)
这是编译器或其他问题吗?我们真的不能解释像这样的一串代码并让它工作吗?
没有技术限制会使实现一种被视为a == b || c
快捷方式的语言变得不可能(甚至太难)a == b || a == c
.问题在于,只有在预期的情况下才能提出这样的规则.
例如,考虑表达式result == null || fileIsClosed
where fileIsClosed
是一个布尔值.当然程序员不会期望这被视为result == null || result == fileIsClosed
.您可以提出额外的规则,例如"仅当右侧操作数||
不是布尔值时才应用替换",但如果您这样做,则替换也不起作用booleanResult == possibleResult1 || possibleResult2
.事实上,关于这个例子的唯一事情就是告诉我们程序员是否打算进行替换,这是变量的名称.显然编译器不能从变量名中推断出含义,因此在每种情况下都不可能做到用户想要的东西,制作简单的规则而没有例外(例如," expr1 || expr2
如果至少有一个expr1
并且expr2
是真的那么真").
总而言之:我们不希望在所有情况下都进行替换,并推断在哪些情况下替换是有意义的,完全准确是不可能的.由于应该很容易推理代码,实现一个可能会或可能不会根据90%的程序员不会知道或理解的规则应用替换的系统会在某些情况下导致混乱的行为,因此不是一个好主意.
答案的一部分是:if (a == b || c)
如果没有上下文或者知道这个表达背后的含义,就无法解释.
考虑以下情况:
如果c
是布尔表达式或布尔值本身会怎么样?然后它可以被解释为:
if (a has the value of b OR c is true)
if (a has the value of b OR c)
现在人类编码这些线的意图是什么?......*想.当要求生成要在机器上执行的目标代码时(我们不像开发人员所预期的那样),我们并不完全知道也不知道编译器.
或者更严重:编译器可以(并且应该)不像人类有时那样猜测.