2708 votes

Comment puis-je vérifier la présence de "undefined" en JavaScript ?

Quelle est la manière la plus appropriée de tester si une variable est indéfinie en JavaScript ?

J'ai vu plusieurs façons possibles :

if (window.myVariable)

Ou

if (typeof(myVariable) != "undefined")

Ou

if (myVariable) // This throws an error if undefined. Should this be in Try/Catch?

9 votes

Voulez-vous vérifier si uniquement undefined ou null également ?

4 votes

6 votes

@Robert - cette question a une réponse acceptée que les réponses ici ont prouvé être fausse.

2955voto

Anurag Points 66470

Si vous souhaitez savoir si une variable a été déclarée, quelle que soit sa valeur, vous pouvez utiliser la commande in L'opérateur est le moyen le plus sûr d'y aller. Considérez cet exemple :

// global scope
var theFu; // theFu has been declared, but its value is undefined
typeof theFu; // "undefined"

Mais dans certains cas, ce n'est pas le résultat escompté, car la variable ou la propriété a été déclarée mais n'a pas été initialisée. Utilisez l'option in pour une vérification plus robuste.

"theFu" in window; // true
"theFoo" in window; // false

Si vous souhaitez savoir si la variable n'a pas été déclarée ou si elle a la valeur undefined puis utilisez le typeof qui garantit le retour d'une chaîne de caractères :

if (typeof myVar !== 'undefined')

Comparaisons directes avec undefined sont gênants car undefined peuvent être écrasés.

window.undefined = "foo";
"foo" == undefined // true

Comme l'a souligné @CMS, ce problème a été corrigé dans la 5e édition d'ECMAScript, et undefined est non réinscriptible.

if (window.myVar) inclura également ces valeurs fantaisistes, ce qui n'est pas très robuste :

false
0
""
NaN
null
undefined

Merci à @CMS d'avoir signalé que votre troisième cas - if (myVariable) peut également générer une erreur dans deux cas. Le premier est lorsque la variable n'a pas été définie, ce qui entraîne une erreur de type ReferenceError .

// abc was never declared.
if (abc) {
    // ReferenceError: abc is not defined
} 

L'autre cas est celui où la variable a été définie, mais possède une fonction getter qui génère une erreur lorsqu'elle est invoquée. Par exemple,

// or it's a property that can throw an error
Object.defineProperty(window, "myVariable", { 
    get: function() { throw new Error("W00t?"); }, 
    set: undefined 
});
if (myVariable) {
    // Error: W00t?
}

8 votes

@Anurag, le troisième cas lancera un ReferenceError si myVariable n'est pas déclaré ...

0 votes

@CMS - merci, je m'en doutais un peu myVariable a été déclaré quelque part, mais sans valeur.

5 votes

@Anurag, de rien, puisque vous parlez de ES5, il est peut-être utile de mentionner que undefined est désormais décrite comme non réinscriptible, non configurable et non dénombrable. Donc, window.undefined = "omg"; échouera simplement en silence ou sera lancée en mode strict.

1335voto

Thomas Eding Points 8651

J'utilise personnellement

myVar === undefined

Attention : Veuillez noter que === est utilisé sur == et que myVar a été précédemment déclaré (pas défini ).


Je n'aime pas typeof myVar === "undefined" . Je pense que c'est long et inutile. (Je peux faire la même chose en moins de code).

Certaines personnes vont s'effondrer de douleur en lisant ceci, en criant : "Attends ! WAAITTT ! !! undefined peut être redéfini !"

Cool. Je connais ça. Mais encore une fois, la plupart des variables en Javascript peuvent être redéfinies. Ne faut-il jamais utiliser un identifiant intégré qui peut être redéfini ?

Si vous suivez cette règle, tant mieux pour vous : vous n'êtes pas un hypocrite.

Le fait est que, pour faire beaucoup de travail réel en JS, les développeurs doivent compter sur les identifiants redéfinissables pour être ce qu'ils sont. Je n'entends pas les gens me dire que je ne devrais pas utiliser setTimeout parce que quelqu'un peut

window.setTimeout = function () {
    alert("Got you now!");
};

En fin de compte, l'argument "il peut être redéfini" pour ne pas utiliser un modèle brut === undefined est bidon.

(Si vous avez toujours peur de undefined étant redéfini, pourquoi intégrez-vous aveuglément du code de bibliothèque non testé dans votre base de code ? Ou encore plus simple : un outil de linting).


De plus, comme le typeof cette technique permet de "détecter" les variables non déclarées :

if (window.someVar === undefined) {
    doSomething();
}

Mais ces deux techniques fuient dans leur abstraction. Je vous conseille vivement de ne pas utiliser cette technique ou même

if (typeof myVar !== "undefined") {
    doSomething();
}

Pensez-y :

var iAmUndefined;

Pour savoir si cette variable est déclarée ou non, vous devrez peut-être recourir à la fonction in opérateur. (Dans de nombreux cas, vous pouvez simplement lire le code O_o).

if ("myVar" in window) {
    doSomething();
}

Mais attendez ! Il y a autre chose ! Et si un prototype de chaîne magique se produisait ? Maintenant, même le supérieur in ne suffit pas. (Bon, j'en ai fini avec cette partie sauf pour dire que pour 99% du temps, === undefined (et ****cough**** typeof ) fonctionne très bien. Si cela vous intéresse vraiment, vous pouvez lire ce sujet à part).

56 votes

Il est marginalement plus probable que undefined pourrait être redéfinie, simplement parce que les gens l'utilisent pour de telles vérifications. Certaines personnes ont l'habitude de placer la constante sur le côté gauche lorsqu'elles effectuent de telles vérifications : if (undefined == someVariable) . Il suffit d'une faute de frappe pour que cela redéfinisse silencieusement undefined : if (undefined = someVariable) .

55 votes

Je n'écris jamais de code qui a undefined sur le LHS. Même si je le faisais, le fait que j'utilise === au lieu de == rend la faute de frappe extrêmement improbable. Mais le fait que == est incorrect est plus inquiétant. Dans tous les cas, un tel bogue est généralement facile à trouver. Un peu comme ce bug : typeof x == "undefned" .

1 votes

== n'est pas nécessairement incorrect : il serait correct si l'intention était de faire correspondre null y undefined . Cependant, je suis d'accord pour dire qu'écrire du code comme ça est une idée assez terrible.

275voto

Tim Down Points 124501

Mise à jour 2020

L'une des raisons pour lesquelles je préfère un typeof (à savoir, que undefined peut être redéfinie) est devenue sans objet avec l'adoption massive d'ECMAScript 5. L'autre, que vous pouvez utiliser typeof pour vérifier le type d'une variable non déclarée, a toujours été une niche. C'est pourquoi je recommande désormais d'utiliser une comparaison directe dans la plupart des situations :

myVariable === undefined

Réponse originale de 2010

Utilisation de typeof est ma préférence. Elle fonctionnera lorsque la variable n'a jamais été déclarée, contrairement à toute comparaison avec l'option == o === ou la coercition de type en utilisant if . ( undefined contrairement à null peut également être redéfini dans les environnements ECMAScript 3, ce qui le rend peu fiable pour la comparaison, bien que la quasi-totalité des environnements courants soient désormais conformes à ECMAScript 5 ou à une version supérieure).

if (typeof someUndeclaredVariable == "undefined") {
    // Works
}

if (someUndeclaredVariable === undefined) { 
    // Throws an error
}

20 votes

Vous pourriez vouloir vérifier si une variable globale particulière représentant un élément de fonctionnalité a déjà été définie. Par exemple, un code de bibliothèque peut souhaiter vérifier que la bibliothèque n'a pas déjà été incluse auparavant.

1 votes

"xyz" dans la fenêtre ou "xyz" dans le self sont bien meilleurs.

0 votes

@JamiePate : Qu'en est-il window.foo = undefined ? "foo" in window retournera true .

86voto

Jacob Relkin Points 90729

Vous pouvez utiliser typeof comme ceci :

if (typeof something != "undefined") {
    // ...
}

9 votes

Ou juste something !== undefined en supposant que vous avez déjà fait var undefined avec précaution.

3 votes

C'est bien de voir que vous avez ajouté les citations maintenant. Cependant, comme mentionné dans ma réponse il est à noter que la comparaison stricte ( !== ) n'est pas nécessaire dans ce cas, puisque typeof retournera toujours une chaîne de caractères.

14 votes

Mathias : l'utilisation de la comparaison stricte ou non stricte est ici une question de goût personnel. Les deux fonctionneront toujours, et aucune n'est plus correcte. Cela peut dépendre du fait que votre position par défaut est de toujours utiliser la comparaison stricte, sauf si la coercition de type est spécifiquement requise (comme le recommande Crockford, par exemple) ou que vous préférez utiliser la comparaison non stricte, sauf lorsque la rigueur est requise.

25voto

Guffa Points 308133

S'il est indéfini, il ne sera pas égal à une chaîne qui contient les caractères "indéfini", car la chaîne n'est pas indéfinie.

Vous pouvez vérifier le type de la variable :

if (typeof(something) != "undefined") ...

Parfois, il n'est même pas nécessaire de vérifier le type. Si la valeur de la variable ne peut pas être évaluée à false lorsqu'elle est définie (par exemple s'il s'agit d'une fonction), alors vous pouvez simplement évaluer la variable. Exemple :

if (something) {
  something(param);
}

15 votes

Les parenthèses ne sont pas nécessaires : typeof est un opérateur, pas une fonction.

7 votes

@Tim - Il peut être utilisé dans les deux sens.

1 votes

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X