Best test for undefined?
in [JavaScript]
|
From: Garrett Smith on 10 May 2010 03:21 nick wrote: > What's the "best" way to determine if a variable is defined? > Depends. If conditional assignment results in an object value, e.g. var x; if(Math.random() > .5) { x = {}; } - then why not use boolean conversion? if(x) { // It has been assigned. } > I see a lot of code that looks like this: > > // example 1 > if (typeof x !== 'undefined') doStuff(x); > > It won't throw an exception if you use it to operate on an undeclared > or deleted identifier. > Works fine for undeclared identifiers and useful for host object checks, too. Identifiers that are declared with var get DontDelete, so don't worry about the case where they were deleted -- they can't be. For other values, it is useful to make different checks, depending on what the code needs ot know. For an example, checking to see if a variable had been assigned a good number value, you might use: var myNum = getPageCoords(ery); if(isFinite(myNum)) { // Move ery to new position. } > > function isDefined (v) { return (v !== void 0) } That tells if a value is not undefined. The isDefined function in the general sense does not provide any advantage over an inline check. It does not say, in the general sense, if `v` has been declared, doese not say if has been assigned a value (undefined is a value), does not say if `v` is a variable, a property of something, the result of trying to get a property that was not available. Consider that, given function scope: (function(){ var undef, myVar; //... var isDef = isDefined(myVar); var isDef2 = myVar !== undef; })(); For the cost of a function call, plus organizing and managing that function, it is not worth it. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Ivan S on 10 May 2010 06:32 On May 10, 5:13 am, David Mark <dmark.cins...(a)gmail.com> wrote: > > // example 1 > > if (typeof x !== 'undefined') doStuff(x); > > You don't need to do a strict comparison there. The typeof operation > returns a string. But isn't strict comparision faster than loose comparision?
From: Dmitry A. Soshnikov on 10 May 2010 07:18 On 10.05.2010 14:32, Ivan S wrote: > On May 10, 5:13 am, David Mark<dmark.cins...(a)gmail.com> wrote: >>> // example 1 >>> if (typeof x !== 'undefined') doStuff(x); >> >> You don't need to do a strict comparison there. The typeof operation >> returns a string. > > But isn't strict comparision faster than loose comparision? Theoretically or practically? If practically, you can test it yourself in every possible implementations and provide us with the results (maybe it will be useful for someone). In theoretically, for e.g. ES3 see 11.9.3 and 11.9.4. Let's compare them (the steps which are essential for our case -- when operands have _the same_ types such as in mentioned `typeof` check): 11.9.3 The Abstract Equality Comparison Algorithm: 1. If Type(x) is different from Type(y), go to step 14. 2. If Type(x) is Undefined, return true. 3. If Type(x) is Null, return true. 4. If Type(x) is not Number, go to step 11. 5. If x is NaN, return false. 6. If y is NaN, return false. 7. If x is the same number value as y, return true. 8. If x is +0 and y is −0, return true. 9. If x is −0 and y is +0, return true. 10. Return false. And now the strict one: 11.9.6 The Strict Equality Comparison Algorithm 1. If Type(x) is different from Type(y), return false. 2. If Type(x) is Undefined, return true. 3. If Type(x) is Null, return true. 4. If Type(x) is not Number, go to step 11. 5. If x is NaN, return false. 6. If y is NaN, return false. 7. If x is the same number value as y, return true. 8. If x is +0 and y is −0, return true. 9. If x is −0 and y is +0, return true. 10. Return false. We can omit step 1, because in our case types are equal -- we have String type. And then you can see that both algorithms are completely equivalent -- (word for word!). So this is a big (and that is petty -- a wide spread) misconception. And this misconception is obtruded by the _subjective meaning_ of some authority. No more, no less. I repeat several times, that checks with `typeof` comparing with strings and using === just looks ridiculous. There is no any sense to use === with such checks. Because there is no logical answer on: (1) you know that `typeof` always produces string; (2) you (yourself, by your own hands, but nobody else) compare this result with a string. Is there any reason (except "I just like", "that's to keep common stylistics", "to be consecutive") to use ===? Of course, if you accept it with reasons-"exceptions" which I just mentioned -- that's your choice and your right. But please (I'm asking everyone), let us don't call == as a "bad practice" and don't say that this is about avoiding errors and etc. arguing (trying to argue) _logically_. This misconception is wide spread in _every_ popular framework. Recently, I was reviewing one book (which should appear soon on bookshelves) and there also == is named as a "bad practice" and everywhere is used === including `typeof` with a string comparison on the right hand side. (although, as a whole, the book is quite good with professional approach). I recommended (if the author still want to keep the general common stylistic using === everywhere), just to make a _small note_ such as: "but in some case, e.g. with typeof operator when we compare its result with strings, === is obsolete". Dmitry.
From: Dmitry A. Soshnikov on 10 May 2010 07:22 On 10.05.2010 15:18, Dmitry A. Soshnikov wrote: [...] > This misconception is wide spread in _every_ popular framework. Yeah, forgot. That's at the same time when they fight trying to save every byte minimizing/obfuscating scripts. And everywhere using === they loose this one byte every time :D But, of course that isn't the main reason. The main reason is -- that should be definite understanding of what we are doing, but not just using that because some authority said so. What about personally me -- I always use ==, and rarely === -- when it is really needed. Dmitry.
From: Dmitry A. Soshnikov on 10 May 2010 07:26
On 10.05.2010 15:18, Dmitry A. Soshnikov wrote: > see 11.9.3 and 11.9.4. Er, should be: 11.9.3 and 11.9.6 of course. Dmitry. |