BIND011: expression-type-mismatch
Obvious literal type errors in expressions
| Code | BIND011 |
| Name | expression-type-mismatch |
| Category | Bindings and expressions (BIND) |
| Default severity | warning |
| Enabled by default | no |
| Fix available | no |
| ign-lint equivalent | none |
What it does
Section titled “What it does”Reports operations whose result is wrong whatever the inputs are, judged from literals only:
- arithmetic (
-,*,/,%,^) with a string literal that is not a number, such as{x} * "two"; Ignition fails to coerce the string at run time (+is string concatenation and is not reported); - comparison with
nullthrough=or!=, such as{x} = null; useisNull({x}), which says what is meant and does not depend on how the operand's type coerces.
The rule never guesses the types of references or function results, which is why it only covers literals. Off by default: it is a style aid more than a bug finder.
Why is this bad?
Section titled “Why is this bad?”The binding evaluates to an error quality (arithmetic on text) or to a comparison that does not test for null the way it reads.
Example
Section titled “Example”{this.custom.count} * "2x"if({view.params.item} = null, "none", {view.params.item})Use instead:
{this.custom.count} * 2if(isNull({view.params.item}), "none", {view.params.item})Generated from the rule metadata by iglint generate-docs; iglint rule BIND011 prints the same page in the terminal. Source: docs/rules/BIND011.md.