On 18 April 2011 07:15, Olov Lassus <[email protected]> wrote: > On Apr 18, 1:18 am, Tim Down <[email protected]> wrote: >> In a typeof comparison, there's no technical reason to favour either >> operator over the other, since they will behave identically. Saving a >> keystroke and a character in the script delivered to the client is a >> tiny but tangible benefit of using ==. The benefits to using === can >> therefore only be stylistic and subjective. > > Using === makes your code easier to reason about in the general case, > even so for typeof. > > I understand the semantics of typeof, you do too, and I wouldn't be > surprised if most in this forum does. But everyone doesn't. Especially > not those who hack JS occasionally. Heck, you'll perhaps need to > remind yourself in the future as well, for whatever reason. > > When anyone reads typeof x === "undefined", they can rely on that > since the simplest and most precise equality operator was used and the > code works, it does what the author intended. There's nothing else > going on. Someone may think that typeof x would be better off > returning undefined (not "undefined") for unresolvable references, but > will stop thinking about it and ponder away writing code resting > assured that the code probably does what it should and what the author > intended, and that it does so in the most effective manner. > > When anyone reads typeof x == "undefined", they need to think about > type coercion since the complex, buggy, imprecise and error-prone > equality operator was used. Someone may question whether typeof x > really returns "undefined" for unresolvable references, since they > think that undefined would make more sense. Could it be that the > author made a mistake which type coercion compensates for? Now they > need to start thinking about whether undefined == "undefined" can > coerce its arguments such that == returns true. That seems reasonable > after all. After a while they learn that it can't and ponder away > writing code, while cursing the author for their wasted time. > > Now consider f(x) == 0, where f is a library function that you don't > know the gory details of. What does f really return? f(x) === 0? Ah, > thanks. > > Do you have other reasons for preferring typeof x == "undefined" over > typeof === "undefined", apart from saving a keystroke? (to nitpick > this isn't the same as saving a character of bandwidth assuming that > you deliver your scripts gzipped, but it doesn't really matter) > > Oh and by the way, I think that typeof would be better off returning > undefined (not "undefined") for unresolvable references. It would > allow the use of the typeof operator for testing whether a reference > is resolvable, no matter what value it may be assigned to.
Frankly, I'm not really that bothered about which operator people choose to use. I used == and != everywhere in my early JavaScripting days without any problems I can recall, and I understand the reasoning behind the current prevalent style of using === and !== instead. I'm not advocating one or the other in particular. What I do object to is being told dogmatically not to use one or the other by tools such as JSLint without any option to override, particularly since the JavaScript community as a whole seems to have swallowed and regularly regurgitates as gospel all of Douglas Crockford's recommendations without apparently thinking about them too deeply. I don't have any problem with reading code that uses both == and === appropriately, and I don't have any problem with people who have learned the "== is bad" mantra having to stop to think briefly while reading such code. Regarding the typeof operator's return value, it is indeed unfortunate that it does not distinguish between an undefined reference and an unresolvable one, but then there are plenty of other distinctions it cannot make, such as between null and any object. I'm not convinced having it return a non-string in some situations would improve the situation. Tim -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
