Categorize more rules

[jpignata]

Defines categories for rules that don't fall under the style category.

[wfleming]

Personally I would argue yoda conditionals are to avoid bug risks (accidental = instead of ==) more than they are for clarity.

[jpignata]

A yoda conditional is when a literal value is being compared to a variable in that order. See http://eslint.org/docs/rules/yoda

[wfleming]

Yes: I'm arguing that their stylistic purpose is to avoid a bug, because if you accidentally type = it's a compile/runtime error instead of a "now this variable has the wrong value and nobody knows why" bug. At least, that's always why I've used them.

[jpignata]

Sorry, I don't think you follow me. It's not about assignment (accidentally typing =), it's about the order used in properly constructed comparisons. From the docs I referenced:

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

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

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

[wfleming]

We are not following each other very well. :)

I understand what Yoda conditionals are: I personally tend to use them. The reason I, personally, use Yoda conditionals is to avoid the bug risk of accidental =. So I would consider not using a Yoda conditional a bug risk, not a clarity decision. That is:

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

is, in my eyes, a bug risk (because it's far too easy to miss/delete one of the = and not realize it). (The risk is somewhat reduced by the fact that almost everybody requires === in JS nowadays, but still.)

That being said, "Bug Risk" may not be an appropriate classification because it only makes sense if your eslintrc requires people to use yoda conditionals. If your eslintrc requires them not to be used, "Clarity" does make more sense. So since either configuration is possible, perhaps "Clarity" is more broadly applicable.

[jpignata]

Ahh, okay, I'm with you now. Agree "Clarity" is probably better. Tying vote is that the default for the rule is "never."

[wfleming]

2 small category disagreements, but LGTM.

[jpignata]

@wfleming Thanks for looking closely!

[gdiggs]

LGTM