On 14/05/2015 18:12, Martin Thomson wrote:
On Thu, May 14, 2015 at 9:40 AM, Gijs Kruitbosch
<gijskruitbo...@gmail.com> wrote:
Crockford offers plenty of
reasons in his book.
I've not read Crockford's book and have no plans to, but there are plenty of
reasons against, too. :-)
Do you want me to send you a copy?
No, but thank you for the offer.
then that does not mean I don't care or don't know - I *know* that
ary.length is a number, and there's no reason to bother with writing "===".
That just says that you are too lazy to hit the key one more time.
And that you don't care to signal to others that you know this.
I mean, obviously the example is simplified. You seem to think that
"===" means "I'm sure this will be the right type". In the same way you
imply that == indicates uncertainty about type (or acceptance of
multiple types), I would argue that when I see === I get suspicious
about whether the code could be failing because it gets passed a
similar-but-different-type value (false vs. null vs. undefined vs. NaN
especially).
Likewise, if I know an argument to a function is either not present or a
non-empty string, and I do:
if (arg) {
dosomethingwitharg(arg);
}
I'm actually perfectly fine with this form. Including something in a
conditional statement is pretty damned explicit as far as I'm
concerned. It's at least as clear as if (!!arg) and easier to read.
(I have a personal bugbear against the falsy-ness of the empty string,
but I can concede that point.)
I don't understand the distinction you're making, then; why is the type
coercion OK here but not for == ? Surely this is being just as "lazy" as
the other case?
I've never seen case
where an explicit check is not possible, and does not help make code
clearer.
I disagree. new String() is my most hated example ("foo" == new
String("foo")) but ("foo" !== new String("foo")), but also in places where
we use implicit truthy/falsy checks, the shorthand 'if (foo)' and/or 'if
(!foo)' is much more useful, clear and concise than trying to check for all
the ways in which foo could be falsy/truthy (and inevitably forgetting
something silly like NaN or types from other windows when using instanceof
or ...).
I have no idea what you are talking about. I have never had cause to
use new String() anywhere. .toString() maybe.
There are more than 1000 hits for "new String(" in MXR, so our codebase
disagrees.
x = "foo";
if (x === "foo") { ... } // is fine
You're arguing that === always makes code clearer, and that explicit
checks are always possible. I disagree with both.
As noted above, === creates just as many uncertainties as == for the
reader. The solution is testing (and in some cases comments), whichever
operator we pick.
Expanding checks which are simple when using == in order to use === is
not always clearer, likewise for other type coercion (where you seem to
be OK with it, which I find hard to understand).
There are cases where explicit checks are impossible. String objects are
wonky and don't compare well, as noted earlier. Likewise, in the
following case:
var foo = [1,2,3];
window.open('bar.html', '_blank', '', foo);
in bar.html, checking the type of foo using instanceof with Array fails.
For builtin Arrays we now have isArray, but this does not work for
custom JS classes or DOM elements.
Also, if you're very serious about wanting to effect this change, you
should probably take this to fx-dev, as the style guide is specifically
about chrome/firefox JS.
~ Gijs
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
