JavaScript条件判断中常量与变量比较顺序的优劣探讨

你提到的第二种把常量放在比较运算符左侧的写法，业内常叫Yoda条件（Yoda Conditions），这种写法的出现和优缺点可以拆解来看：

核心设计目的：规避赋值错误 #

最关键的原因是防止把比较运算符===（或==）不小心写成赋值运算符=。

• 常规写法if(foo === 'success')如果手滑写成if(foo = 'success')，代码不会报错：'success'会被赋值给foo，而赋值表达式的结果就是右边的值，条件永远为真，这会导致隐蔽的逻辑bug，很难排查。
• 但Yoda写法if('success' === foo)如果写成if('success' = foo)，JS会直接抛出语法错误——因为字符串常量是不可变的，无法被赋值，错误会在运行第一时间暴露，不会留到逻辑执行阶段。

优缺点对比 #

优点 #

• 提前捕获低级错误：在编译或运行初期就能发现“把比较写成赋值”的失误，避免后续排查麻烦；
• 适配多语言场景：在Java、C这类强类型语言中，这种写法的实用性更强——比如把==写成=时，变量类型匹配的话不会报错，而常量在前会直接触发编译错误。

缺点 #

• 可读性降低：不符合日常语言的表达逻辑（我们习惯说“如果foo等于success”，而非“如果success等于foo”），复杂条件下会增加阅读成本；
• 现代环境下必要性减弱：现在主流JS编辑器（如VS Code）、代码检查工具（如ESLint）会主动检测if(foo = 'success')这类可疑的赋值操作并给出警告；另外如果变量是用const声明的（比如你例子里的foo），写foo = 'success'会直接抛出TypeError，根本不会执行到逻辑里。

哪种写法更优？ #

没有绝对的标准答案，主要看团队规范和项目场景：

• 如果团队新人较多、对低级错误零容忍，或者项目需要兼容多语言开发习惯，Yoda条件是稳妥的选择；
• 如果追求代码的自然可读性，且项目有完善的代码检查机制，常规写法会更友好。

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