question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Rule Request: prevent equality comparison with booleans

See original GitHub issue

Please describe what the rule should do:

Disallow ==, ===, !=, and !== when one (or both) of the operands are true or false.

What category of rule is this? (place an “X” next to just one item)

[X] Enforces code style [ ] Warns about a potential error [ ] Suggests an alternate way of doing something [ ] Other (please specify:)

Provide 2-3 code examples that this rule will warn about:

x === true
false != x
true === true

Why should this rule be included in ESLint (instead of a plugin)?

This is an extremely basic style issue that has cropped up in just about every codebase I’ve ever worked in.

Issue Analytics

  • State:closed
  • Created 6 years ago
  • Reactions:3
  • Comments:12 (6 by maintainers)

github_iconTop GitHub Comments

2reactions
not-an-aardvarkcommented, Jan 19, 2018

Thanks for your interest in improving ESLint. Unfortunately, it looks like this issue didn’t get consensus from the team, so I’m closing it. We define consensus as having three 👍s from team members, as well as a team member willing to champion the proposal. This is a high bar by design – we can’t realistically accept and maintain every feature request in the long term, so we only accept feature requests which are useful enough that there is consensus among the team that they’re worth adding.

Since ESLint is pluggable and can load custom rules at runtime, the lack of consensus among the ESLint team doesn’t need to be a blocker for you using this in your project, if you’d find it useful. It just means that you would need to implement the rule yourself, rather than using a bundled rule that is packaged with ESLint.

2reactions
platinumazurecommented, Dec 21, 2017

Just add ^ and $ anchors and that should avoid strings containing. You could also try using left.raw instead of left.value, that might avoid false positives for “true”/“false” strings. Sorry for the mix-up.

On Dec 21, 2017 11:40 AM, “Luke M Willis” notifications@github.com wrote:

@platinumazure https://github.com/platinumazure I set up that rule, slightly modified to account for true and false:

“no-restricted-syntax”: [ “error”, { “selector”: “BinaryExpression[operator=/(==|===|!=|!==)/][left.value=/(true|false)/], BinaryExpression[operator=/(==|===|!=|!==)/][right.value=/(true|false)/]”, “message”: “Don’t compare for equality against boolean literals” } ]

This catches all the issues, but also captures x === ‘true’ and “the value is false” != x.

I could probably write a regex that excluded strings, but that would be pretty fragile.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/eslint/eslint/issues/9743#issuecomment-353412274, or mute the thread https://github.com/notifications/unsubscribe-auth/AARWet6JFYCDc035cP7_Rc7IrmwZ07kgks5tCpgcgaJpZM4RIy_s .

Read more comments on GitHub >

github_iconTop Results From Across the Web

Is there a TSLint/ESLint rule to prevent (boolean === true) type ...
Show activity on this post. The selector disallows usage of == , === , != , and !== when either (or both) of...
Read more >
Rule Request: Discourage comparing Bool value with `true` or ...
New rule request​​ The usage of == or != operators for checking if the Bool value is true or false should be discouraged...
Read more >
no-unnecessary-boolean-literal-compare - TypeScript ESLint
This rule ensures that you do not include unnecessary comparisons with boolean literals. A comparison is considered unnecessary if it checks a boolean...
Read more >
Why Use !boolean_variable Over boolean_variable == false
It happens that 0 is the only value considered to be false, so comparison for equality to false will work; if (!cond) and...
Read more >
Java static code analysis: Boxed "Boolean" should be avoided ...
When boxed type java.lang.Boolean is used as an expression it will throw NullPointerException if the value is null as defined in Java Language...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found