Rule Request: prevent equality comparison with booleans
See original GitHub issuePlease 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:
- Created 6 years ago
- Reactions:3
- Comments:12 (6 by maintainers)
Top 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 >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
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.
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: