短路求值替代简单if语句是否属于良好编程实践？

很多开发者会用my_flag && doStuff()替代简单的if条件执行，但这种写法并非没有争议，主要的反对理由和潜在问题包括：

• 可读性的认知差异：短路写法的简洁性是建立在读者熟悉布尔短路求值特性的基础上的。对于新手或者习惯了传统if语句的开发者来说，这种写法的语义不够直观——一眼看过去可能会误以为这是一个布尔判断表达式，而非“条件满足时执行函数”的逻辑。相比之下，if(my_flag) { doStuff(); }的语义直白，几乎没有理解成本。

• 调试与维护成本：当doStuff()需要调试、添加日志或者修改逻辑时，短路写法的结构不如if块清晰。比如想在执行doStuff()前加一句日志，短路写法只能拆成多行或者硬塞进去，而if块可以直接在大括号内添加代码。部分调试器对这种表达式形式的函数调用，也不会像if分支那样明确标记执行状态。

• 扩展性差：如果后续需求变更，需要在条件满足时执行多个操作，短路写法的局限性就会凸显。比如要新增doAnotherThing()：

  // 短路写法要么变成这样（还要求doStuff()返回真值）
  my_flag && doStuff() && doAnotherThing();
  // 要么只能被迫改成if语句
  if(my_flag) {
    doStuff();
    doAnotherThing();
  }
  

  显然if语句的扩展性要好得多，不需要额外修改语法逻辑。

• 代码风格一致性问题：多数团队的编码规范会明确要求用if语句处理这种条件执行场景，保持代码风格的统一。如果团队内普遍使用if，突然出现短路写法，会打破一致性，增加其他开发者的理解和维护成本。

• 潜在的语义误用：如果doStuff()有返回值，开发者可能会误将这个短路表达式的结果赋值给变量，比如写成const res = my_flag && doStuff();——当my_flag为false时，res会是false，这往往不是预期的结果，而if语句不存在这种误用风险。

内容的提问来源于stack exchange，提问作者FranAcuna