Rule proposal: Put actual values first and expected values second in assertion

[jfmengels]

When you write assertions, like t(a, b), the first argument is the value to evaluate, and the second is the expected value to compare it to. But you can actually mix the two arguments and everything would work as expected, except that the error messages will be a bit more confusing because it will swap the expected and received values.

I see it every so often that the arguments are swapped. Not very often, but it can't hurt to have it IMO.

I propose a rule that requires you to put your expressions as the first argument, rather than on the right. Or in other words, as this is probably will be how we'll write the rule, put static expressions on the right.

Invalid

t.is(1, expression);
t.deepEqual({}, expression);
t.true(1 === foo); // Also handle this? Probably, as power-assert considers `1` as the value

Valid

t.is(expression, 1);
t.deepEqual(expression, {});
t.true(foo === 1);
t.is(expression, otherExpression);

Implementation side-note: We could probably use this function to help find out whether an expression is static or not. (I haven't yet published it, but I can do it soonish).

As for the name: no-expected-left, put-expected-right? :/

---

Note: This issue has a bounty, so it's expected that you are an experienced programmer and that you give it your best effort if you intend to tackle this. Don't forget, if applicable, to add tests, docs (double-check for typos). And don't be sloppy. Review your own diff multiple times and try to find ways to improve and simplify your code. Instead of asking too many questions, present solutions. The point of an issue bounty is to reduce my workload, not give me more. Include a 🦄 in your PR description to indicate that you've read this. Thanks for helping out 🙌 - @sindresorhus

---

IssueHunt Summary

ninevra has been rewarded.

Backers (Total: $40.00)

• issuehunt ($40.00)

Submitted pull Requests

• #307 Catch & fix out-of-order assertion arguments

---

Tips

• Checkout the Issuehunt explorer to discover more funded issues.
• Need some help from other developers? Add your repositories on IssueHunt to raise funds.

[vadimdemedes]

Hmm, the issue title says "Put expected values first", but later you propose "put expected values right":

As for the name: no-expected-left, put-expected-right?

I guess issue title should've been "Put actual values first"?

[jfmengels]

Yes, my bad 😅

[sindresorhus]

👍

Would it make sense to make this an option in the assertion-arguments rule instead? Not sure about it, but thought I'd bring it up. Could be an actualFirst: 'always' option.

I assume this would be auto-fixable?

[jfmengels]

Yes this sounds right. Not sure why it would be behind an option though. I'd say let's add the error and publish a new major. And yes, this sounds fixable.

Do you think this should work for the power assert case too? I'm afraid it would conflict with people coding with the core yoda rule. Both rules are fixable, so it could create an infinite loop if we tried to autofix that one too :s

[sindresorhus]

Not sure why it would be behind an option though. I'd say let's add the error and publish a new major. And yes, this sounds fixable.

👍 Not sure why I suggested an option either. No option needed!

Do you think this should work for the power assert case too? I'm afraid it would conflict with people coding with the core yoda rule. Both rules are fixable, so it could create an infinite loop if we tried to autofix that one too :s

Nah, already covered by the yoda rule. Not worth the hassle.

[jfmengels]

Nah, already covered by the yoda rule.

I meant for people actually enforcing yoda style (i.e. putting values to compare to on the left-side). But I agree, not worth the hassle, especially compared to how many devs do that.

[issuehunt-oss]

@issuehunt has funded $40.00 to this issue.

---

• Submit pull request via IssueHunt to receive this reward.
• Want to contribute? Chip in to this issue via IssueHunt.
• Checkout the IssueHunt Issue Explorer to see more funded issues.
• Need help from developers? Add your repository on IssueHunt to raise funds.