Skip to main content
Stack Overflow
  1. About
  2. For Teams

Return to Answer

cleaner opening structure
Source Link
Ry-
  • 226.3k
  • 56
  • 496
  • 504

Despite being vehemently recommended by many otherMany answers here are vehement in recommending typeof, but typeof is a bad choice. It should nevernever be used for checking whether variables have the value undefined, because it acts as a combined check for the value undefined and for whether a variable exists. In the vast majority of cases, you know when a variable exists, and typeof will just introduce the potential for a silent failure if you make a typo in the variable name or in the string literal 'undefined'.

Despite being vehemently recommended by many other answers here, typeof is a bad choice. It should never be used for checking whether variables have the value undefined, because it acts as a combined check for the value undefined and for whether a variable exists. In the vast majority of cases, you know when a variable exists, and typeof will just introduce the potential for a silent failure if you make a typo in the variable name or in the string literal 'undefined'.

Many answers here are vehement in recommending typeof, but typeof is a bad choice. It should never be used for checking whether variables have the value undefined, because it acts as a combined check for the value undefined and for whether a variable exists. In the vast majority of cases, you know when a variable exists, and typeof will just introduce the potential for a silent failure if you make a typo in the variable name or in the string literal 'undefined'.

void 0 isn’t good either
Source Link
Ry-
  • 226.3k
  • 56
  • 496
  • 504
  • that reading an "uninitialized" variable (var foo) or parameter (function bar(foo) { ... }, called as bar()) will fail. This is simply not true – variables without explicit initialization and parameters that weren’t given values always become undefined, and are always in scope.

  • that undefined can be overwritten. There’s a lot more to this.It’s true that undefined is notisn’t a keyword in JavaScript. Instead, it’s a property on the global object with the Undefined value. However, since ES5, this property has beenbut it read-onlyis read-only and non-configurablenon-configurable. No modern browser will allow theThere are other built-ins you probably don’t avoid despite their non-keyword status (undefinedObject property to be changed, and as of 2017 this has been the case for a long time. Lack of strict mode doesn’t affect undefined’s behaviour either – it just makes statements like undefined = 5Math do nothing instead of throwing. Since it isn’t a keyword, though, you can declare variables with the name undefinedNaN,...) and those variables could be changedpractical code usually isn’t written in an actively malicious environment, makingso this once-common pattern:

     (function (undefined) {
     // ...
     })()
    

    more dangerous than using the globalisn’t a good reason to be worried about undefined. If(But if you have to be ES3-compatibleare writing a code generator, replace undefined withfeel free to use void 0 – don’t resort to typeof. (void has always been a unary operator that evaluates to the Undefined value for any operand.)

1 unusual choice of example variable name? this is real dead code from the NoScript extension for Firefox.
2 don’t assume that not knowing what’s in scope is okay in general, though. bonus vulnerability caused by abuse of dynamic scope: Project Zero 1225
3 once again assuming an ES5+ environment and that undefined refers to the undefined property of the global object. substitute void 0 otherwise.

  • that reading an "uninitialized" variable (var foo) or parameter (function bar(foo) { ... }, called as bar()) will fail. This is simply not true – variables without explicit initialization and parameters that weren’t given values always become undefined, and are always in scope.

  • that undefined can be overwritten. There’s a lot more to this. undefined is not a keyword in JavaScript. Instead, it’s a property on the global object with the Undefined value. However, since ES5, this property has been read-only and non-configurable. No modern browser will allow the undefined property to be changed, and as of 2017 this has been the case for a long time. Lack of strict mode doesn’t affect undefined’s behaviour either – it just makes statements like undefined = 5 do nothing instead of throwing. Since it isn’t a keyword, though, you can declare variables with the name undefined, and those variables could be changed, making this once-common pattern:

     (function (undefined) {
     // ...
     })()
    

    more dangerous than using the global undefined. If you have to be ES3-compatible, replace undefined with void 0 – don’t resort to typeof. (void has always been a unary operator that evaluates to the Undefined value for any operand.)

1 unusual choice of example variable name? this is real dead code from the NoScript extension for Firefox.
2 don’t assume that not knowing what’s in scope is okay in general, though. bonus vulnerability caused by abuse of dynamic scope: Project Zero 1225
3 once again assuming an ES5+ environment and that undefined refers to the undefined property of the global object. substitute void 0 otherwise.

  • that reading an "uninitialized" variable (var foo) or parameter (function bar(foo) { ... }, called as bar()) will fail. This is simply not true – variables without explicit initialization and parameters that weren’t given values always become undefined, and are always in scope.

  • that undefined can be overwritten. It’s true that undefined isn’t a keyword, but it is read-only and non-configurable. There are other built-ins you probably don’t avoid despite their non-keyword status (Object, Math, NaN...) and practical code usually isn’t written in an actively malicious environment, so this isn’t a good reason to be worried about undefined. (But if you are writing a code generator, feel free to use void 0.)

1 unusual choice of example variable name? this is real dead code from the NoScript extension for Firefox.
2 don’t assume that not knowing what’s in scope is okay in general, though. bonus vulnerability caused by abuse of dynamic scope: Project Zero 1225
3 once again assuming an ES5+ environment and that undefined refers to the undefined property of the global object.

actually i’m doing the caveat
Source Link
Ry-
  • 226.3k
  • 56
  • 496
  • 504

Despite being vehemently recommended by many other answers here, typeof is a bad choice. It should never be used for checking whether variables have the value undefined, because it acts as a combined check for the value undefined and for whether a variable exists. In the vast majority of cases, you know when a variable exists, and typeof will just introduce the potential for a silent failure if you make a typo in the variable name or in the string literal 'undefined'.

var foo = ...;
if (typeof foo === 'undefned') {
 // ^
 // misspelled – this will never run, but it won’t throw an error!
}

With how variables work out of the way, it’s time to address the actual question: object properties. There is no reason to ever use typeof for object properties. The earlier caveats aboutexception regarding feature detection don’tdoesn’t apply here – typeof only has special behaviour on variables, and expressions that reference object properties are not variables.

Something else to consider when it comes to object properties is whether you really want to check for undefined at all. A given property name can be absent on an object (producing the value undefined when read), present on the object itself with the value undefined, present on the object’s prototype with the value undefined, or present on either of those with a non-undefined value. 'key' in obj will tell you whether a key is anywhere on an object’s prototype chain, and Object.prototype.hasOwnProperty.call(obj, 'key') will tell you whether it’s directly on the object. I won’t go into detail in this answer about prototypes and using objects as string-keyed maps, though, because it’s mostly intended to counter all the bad advice in other answers regardlessirrespective of the possible interpretations of the original question. Read up on object prototypes on MDN for more!

Despite being vehemently recommended by many other answers here, typeof is a bad choice. It should never be used for checking whether variables have the value undefined, because it acts as a combined check for the value undefined and for whether a variable exists. In the vast majority of cases, you know when a variable exists, and typeof will just introduce the potential for a silent failure if you make a typo in the variable name.

With how variables work out of the way, it’s time to address the actual question: object properties. There is no reason to ever use typeof for object properties. The earlier caveats about feature detection don’t apply here – typeof only has special behaviour on variables, and expressions that reference object properties are not variables.

Something else to consider when it comes to object properties is whether you really want to check for undefined at all. A given property name can be absent on an object (producing the value undefined when read), present on the object itself with the value undefined, present on the object’s prototype with the value undefined, or present on either of those with a non-undefined value. 'key' in obj will tell you whether a key is anywhere on an object’s prototype chain, and Object.prototype.hasOwnProperty.call(obj, 'key') will tell you whether it’s directly on the object. I won’t go into detail in this answer about prototypes and using objects as string-keyed maps, though, because it’s mostly intended to counter all the bad advice in other answers regardless of the possible interpretations of the original question. Read up on object prototypes on MDN for more!

Despite being vehemently recommended by many other answers here, typeof is a bad choice. It should never be used for checking whether variables have the value undefined, because it acts as a combined check for the value undefined and for whether a variable exists. In the vast majority of cases, you know when a variable exists, and typeof will just introduce the potential for a silent failure if you make a typo in the variable name or in the string literal 'undefined'.

var foo = ...;
if (typeof foo === 'undefned') {
 // ^
 // misspelled – this will never run, but it won’t throw an error!
}

With how variables work out of the way, it’s time to address the actual question: object properties. There is no reason to ever use typeof for object properties. The earlier exception regarding feature detection doesn’t apply here – typeof only has special behaviour on variables, and expressions that reference object properties are not variables.

Something else to consider when it comes to object properties is whether you really want to check for undefined at all. A given property name can be absent on an object (producing the value undefined when read), present on the object itself with the value undefined, present on the object’s prototype with the value undefined, or present on either of those with a non-undefined value. 'key' in obj will tell you whether a key is anywhere on an object’s prototype chain, and Object.prototype.hasOwnProperty.call(obj, 'key') will tell you whether it’s directly on the object. I won’t go into detail in this answer about prototypes and using objects as string-keyed maps, though, because it’s mostly intended to counter all the bad advice in other answers irrespective of the possible interpretations of the original question. Read up on object prototypes on MDN for more!

Get to the point a bit better
Source Link
Ry-
  • 226.3k
  • 56
  • 496
  • 504
Loading
seriously though
Source Link
Ry-
  • 226.3k
  • 56
  • 496
  • 504
Loading
Removed some meta information (but perhaps it would be better to remove all of it, provide (specific) comments to all or some of the other answers, and refer to this answer (with a true HTML link)?).
Source Link
Peter Mortensen
  • 31.3k
  • 22
  • 110
  • 134
Loading
Note about == null, which is the common (and more concise) idiom
Source Link
Ry-
  • 226.3k
  • 56
  • 496
  • 504
Loading
Source Link
Ry-
  • 226.3k
  • 56
  • 496
  • 504
Loading
lang-js

AltStyle によって変換されたページ (->オリジナル) /