On 14/05/2015 17:14, Martin Thomson wrote:
On Thu, May 14, 2015 at 5:17 AM, Gijs Kruitbosch
<gijskruitbo...@gmail.com> wrote:
On 14/05/2015 01:21, Martin Thomson wrote:
On Wed, May 13, 2015 at 4:54 PM, Matthew N.
<mattn+firefox-...@mozilla.com> wrote:
"In JavaScript, == is preferred to ===." from
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Operators
Ahh, that's where it was hiding. Can we reverse that statement please?
Concurring with Mike in the other branch of the original thread, I would
prefer not to (for non-test code). You've also provided no arguments as to
why we should be doing this.
I thought that this was understood.
Do you think the people that wrote the style guide (not me, so I'm not
trying to be defensive over the document, to be clear) did not
understand what they 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. :-)
To summarize, == uses implicit type coercion.
I think everyone reading this thread, and certainly everyone who wrote
that style guide, is aware of this.
It says that you don't care or that you don't know what something is.
Well, no, not exactly. If I write:
var ary = "a,b,c".split(',')
if (ary.length == 2)
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 "===".
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);
}
then that doesn't mean I don't know or care about the implicit type
coercion which happens, just that it would be more arduous to write
comparisons with undefined.
In fact, in general I would say we write APIs and functions and so on
where the type is meant to not matter, and having any where different
values that are loosely but not strictly equivalent have different
meanings is frowned upon. In other words, we should strive for code
where the comparison operator used does not matter.
The only real reason I've seen to pick === over == is performance, and
most of our chrome JS code is not in hot code paths, and we have other
overhead (XPCOM calls, DOM calls, layout flushes) which are a much
bigger perf issue.
At a more meta-level, I would personally also argue that the spirit of
JS-the-language is one where type checks are rare and therefore allow
easily mocking/replacing "real" things with "lookalike" things (I think
the patch I wrote here:
https://bugzilla.mozilla.org/show_bug.cgi?id=341767 is still one of my
favourite examples of (ab)using this tendency). Strict checks throw that
kind of thing away, and I think that would be a net loss (when not
writing code where perf is paramount, for which we have things like asmjs).
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 ...).
~ Gijs
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
