If there was a linter rule I could turn on to require booleans in if-conditions, I'd enable it.
`!!` might seem silly, but it's a hint that you intended for coercion to happen. A similar but better example would be preferring `if (x > 0)` over `if (x)` even though non-zero is truthy.
There's an even better case for returning `!!x` from a function even though you could return `x` and let the call-site coerce it. The problem with that is that the call-site can build a dependency on the value of `x` beyond truthy vs falsey.
In a weakly typed language like Javascript, I don't think you'll ever regret being a little more explicit.
> `!!` might seem silly, but it's a hint that you intended for coercion to happen.
"Silly" is in the eye of the beholder, of course. But it is definitely redundant. Using a value in an if statement is not just a hint, but an explicit guarantee that all you are doing with the value is testing it for truthiness. !! adds no information or insight that isn't already there.
> A similar but better example would be preferring `if (x > 0)` over `if (x)` even though non-zero is truthy.
Obviously you know this, but if( x > 0 ) is not the same thing as if( x ). You can't substitute one for the other: a truthiness test on x is different from testing the numeric value of x for being greater than zero. If x is -1, the two statements will do different things.
> There's an even better case for returning `!!x` from a function even though you could return `x` and let the call-site coerce it. The problem with that is that the call-site can build a dependency on the value of `x` beyond truthy vs falsey.
That's a completely different situation. When you return a value from a function, there is no guaranteed truthiness test as there is with an if statement. You're just returning a value "as is".
So for example, if you have a function that creates some private object and it's defined to return a truthy or falsy value to tell you if the object was created, it could be tempting to say "I have a variable with a reference to the object I'm creating or null if it failed. I can just return that variable!"
As you mentioned, the caller could hold a reference to that return value, thus holding a reference to the object that isn't necessary - and could lead to a memory leak. By using "return !! myObject;" instead, you avoid passing the object itself back to the caller and just give them a true/false value instead. This is a good thing to do.
But an if statement is not the same thing. The if statement already has a guarantee that all it will do with the value is test it for truthiness and not keep any reference to it. Adding !! doesn't convey any information to the reader that isn't already there.
I like being explicit too, but I don't like adding extra verbiage to something that is already completely explicit.
It doesn't play well with the vscode tslint extension for some reason (doesn't show up at all) so you need to run tslint manually to see the errors.. but it's better than nothing.
> In a weakly typed language like Javascript, I don't think you'll ever regret being a little more explicit.
"!!" is not needed in the shown case. It might be needed if you want to pass somewhere or return "boolean" value, but in the example it's only the "if" thing.
If there was a linter rule I could turn on to require booleans in if-conditions, I'd enable it.
`!!` might seem silly, but it's a hint that you intended for coercion to happen. A similar but better example would be preferring `if (x > 0)` over `if (x)` even though non-zero is truthy.
There's an even better case for returning `!!x` from a function even though you could return `x` and let the call-site coerce it. The problem with that is that the call-site can build a dependency on the value of `x` beyond truthy vs falsey.
In a weakly typed language like Javascript, I don't think you'll ever regret being a little more explicit.