← Back to rules

eslint/yoda Style

🛠️ An auto-fix is available for this rule.

What it does

Require or disallow "Yoda" conditions. This rule aims to enforce consistent style of conditions which compare a variable to a literal value.

Why is this bad?

Yoda conditions are so named because the literal value of the condition comes first while the variable comes second. For example, the following is a Yoda condition:

if ("red" === color) {
}

This is called a Yoda condition because it reads as, "if red equals the color", similar to the way the Star Wars character Yoda speaks. Compare to the other way of arranging the operands:

if (color === "red") {
  // ...
}

This typically reads, "if the color equals red", which is arguably a more natural way to describe the comparison. Proponents of Yoda conditions highlight that it is impossible to mistakenly use = instead of == because you cannot assign to a literal value. Doing so will cause a syntax error and you will be informed of the mistake early on. This practice was therefore very common in early programming where tools were not yet available. Opponents of Yoda conditions point out that tooling has made us better programmers because tools will catch the mistaken use of = instead of == (ESLint will catch this for you). Therefore, they argue, the utility of the pattern doesn't outweigh the readability hit the code takes while using Yoda conditions.

Examples

never

Examples of incorrect code for the default "never" option:

if ("red" === color) {
  // ...
}
if (`red` === color) {
  // ...
}
if (`red` === `${color}`) {
  // ...
}

if (true == flag) {
  // ...
}

if (0 <= x && x < 1) {
  // ...
}

Examples of correct code for the default "never" option:

if (5 & value) {
  // ...
}

if (value === "red") {
  // ...
}

if (value === `red`) {
  // ...
}

if (`${value}` === `red`) {
}

exceptRange

Examples of correct code for the "never", { "exceptRange": true } options:

function isReddish(color) {
  return color.hue < 60 || 300 < color.hue;
}

if (x < -1 || 1 < x) {
  // ...
}

if (count < 10 && 0 <= rand && rand < 1) {
  // ...
}

if (`blue` < x && x < `green`) {
  // ...
}

function howLong(arr) {
  return 0 <= arr.length && arr.length < 10 ? "short" : "long";
}

onlyEquality

Examples of correct code for the "never", { "onlyEquality": true } options:

if (x < -1 || 9 < x) {
}

if (x !== "foo" && "bar" != x) {
}

if (x !== `foo` && `bar` != x) {
}

always

Examples of incorrect code for the "always" option:

if (color == "blue") {
  // ...
}

if (color == `blue`) {
  // ...
}

Examples of correct code for the "always" option:

if ("blue" == value) {
  // ...
}

if (`blue` == value) {
  // ...
}

if (`blue` == `${value}`) {
  // ...
}

if (-1 < str.indexOf(substr)) {
  // ...
}

Configuration

The 1st option

type: "never" | "always"

"never"

The default "never" option can have exception options in an object literal, via exceptRange and onlyEquality.

"always"

The "always" option requires that literal values must always come first in comparisons.

The 2nd option

This option is an object with the following properties:

exceptRange

type: boolean

default: false

If the "exceptRange" property is true, the rule allows yoda conditions in range comparisons which are wrapped directly in parentheses, including the parentheses of an if or while condition. A range comparison tests whether a variable is inside or outside the range between two literal values.

onlyEquality

type: boolean

default: false

If the "onlyEquality" property is true, the rule reports yoda conditions only for the equality operators == and ===. The onlyEquality option allows a superset of the exceptions which exceptRange allows, thus both options are not useful together.

How to use

To enable this rule using the config file or in the CLI, you can use:

Config (.oxlintrc.json)

{
  "rules": {
    "yoda": "error"
  }
}

CLI

oxlint --deny yoda

References

• Rule Source