À quel point est-il vraiment dangereux en JavaScript de supposer qu'undefined n'est pas écrasé?

Chaque fois que quelqu'un mentionne un test undefined, il est signalé que ce undefinedn'est pas un mot-clé, il peut donc être défini sur"hello" , vous devriez donc l'utiliser à la typeof x == "undefined" place. Cela me semble ridicule. Personne ne ferait jamais ça, et s'ils le faisaient, ce serait une raison suffisante pour ne jamais utiliser le code qu'ils ont écrit ... n'est-ce pas?

J'ai trouvé un exemple de quelqu'un qui s'est accidentellement mis undefinedà null, et cela a été donné comme une raison pour éviter de supposer que ce undefinedn'est pas écrasé. Mais s'ils avaient fait cela, le bogue n'aurait pas été détecté, et je ne vois pas en quoi c'est mieux.

En C ++, tout le monde sait que c'est légal de le dire #define true false, mais personne ne vous conseille jamais d'éviter trueet d'utiliser à la 0 == 0place. Vous supposez simplement que personne ne serait jamais assez gros pour faire ça, et s'ils le font, ne faites plus jamais confiance à leur code.

Cela a-t-il déjà mordu quelqu'un où quelqu'un d'autre a été assigné undefined(exprès) et cela a cassé votre code, ou est-ce plus une menace hypothétique? Je suis prêt à tenter ma chance pour rendre mon code légèrement plus lisible. Est-ce vraiment une mauvaise idée?

Pour répéter, je ne demande pas comment se protéger contre les réaffectations indéfinies. J'ai déjà vu ces astuces écrites 100 fois. Je demande à quel point il est dangereux de ne pas utiliser ces astuces.

Non, je ne l'ai jamais fait. C'est principalement parce que je développe sur des navigateurs modernes, qui sont pour la plupart conformes à ECMAScript 5. La norme ES5 dicte qu'il undefinedest désormais en lecture seule. Si vous utilisez le mode strict (vous devriez), une erreur sera générée si vous essayez accidentellement de le modifier.

undefined = 5;
alert(undefined); // still undefined

'use strict';
undefined = 5; // throws TypeError

Ce que vous ne devez pas faire est de créer votre propre portée, modifiable undefined:

(function (undefined) {
    // don't do this, because now `undefined` can be changed
    undefined = 5;
})();

Constant va bien. Encore inutile, mais bien.

(function () {
    const undefined = void 0;
})();

Aucun code approprié ne fera une telle chose. Mais vous ne pouvez jamais savoir ce que certains développeurs intelligents en herbe ou un plugin / bibliothèque / script que vous utilisez ont fait. D'un autre côté, il est extrêmement improbable et les navigateurs modernes ne permettront pas du tout l'écrasement undefined, donc si vous utilisez un tel navigateur pour le développement, vous remarquerez rapidement si un code tente de l'écraser.

Et même si vous ne l'avez pas demandé, de nombreuses personnes trouveront probablement cette question en recherchant le problème le plus courant de «comment se protéger contre une redéfinition undefined», je vais donc y répondre quand même:

Il existe un très bon moyen d'obtenir un vraiment indéfini, undefined quel que soit l'âge du navigateur:

(function(undefined) {
    // your code where undefined is undefined
})();

Cela fonctionne car un argument qui n'est pas spécifié est toujours undefined . Vous pouvez également le faire avec une fonction qui accepte de vrais arguments, par exemple comme celui-ci lorsque vous utilisez jQuery. C'est généralement une bonne idée de garantir un environnement sain de cette manière:

(function($, window, undefined) {
    // your code where undefined is undefined
})(jQuery, this);

Ensuite, vous pouvez être sûr qu'à l'intérieur de cette fonction anonyme, les choses suivantes sont vraies:

• $ === jQuery
• window === [the global object]
• undefined === [undefined].

Cependant, notez que parfois typeof x === 'undefined'est réellement nécessaire: si la variable xn'a jamais été définie sur une valeur (contrairement à celle définie sur undefined), la lecture xd'une manière différente, par exemple if(x === undefined), provoquera une erreur. Cela ne s'applique pas aux propriétés des objets, donc si vous savez que yc'est toujours un objet, if(y.x === undefined)c'est parfaitement sûr.

Il y a une solution simple à cela: comparer void 0ce qui n'est toujours pas défini.

Notez que vous devez éviter ==car cela peut contraindre les valeurs. Utilisez plutôt ===(et !==).

Cela dit, la variable non définie peut être définie par erreur si quelqu'un écrit =au lieu de ==comparer quelque chose avec undefined.

Vous seul savez quel code vous utilisez, et donc à quel point il est dangereux. On ne peut pas répondre à cette question de la manière dont vous avez précisé que vous voulez qu'elle réponde.

1) Créez une stratégie d'équipe, interdisez de redéfinir undefined, en la réservant pour son utilisation plus populaire. Scannez votre code existant pour une affectation à gauche non définie.

2) Si vous ne contrôlez pas tous les scénarios, si votre code est utilisé en dehors de situations que vous ou vos politiques contrôlez, alors votre réponse est évidemment différente. Scannez le code qui utilise vos scripts. Heck, scannez le Web pour des statistiques sur l'affectation de gauche non définie si vous le souhaitez, mais je doute que cela ait été fait pour vous, car il est plus facile de simplement poursuivre la réponse n ° 1 ou n ° 3 ici à la place.

3) Et si cette réponse n'est pas assez bonne, c'est probablement parce que, encore une fois, vous avez besoin d'une réponse différente. Peut-être que vous écrivez une bibliothèque populaire qui sera utilisée dans les pare-feu d'entreprise et que vous n'avez pas accès au code d'appel. Ensuite, utilisez l'une des autres bonnes réponses ici. Notez que la bibliothèque jQuery populaire pratique l'encapsulation sonore et commence:

(function( window, undefined ) {

Vous seul pouvez répondre à votre question de la manière spécifique que vous recherchez. Que dire de plus?

edit: ps si vous voulez vraiment mon avis, je vais vous dire que ce n'est pas du tout dangereux. Tout ce qui serait si susceptible de causer des défauts (comme l'attribution à undefined, qui est évidemment un comportement à risque bien documenté) est en soi un défaut. C'est le défaut qui est le risque. Mais ce n'est que dans mes scénarios, où je peux me permettre d'avoir cette perspective. Comme je vous le recommande, j'ai répondu à la question pour mes cas d'utilisation.

Il est sûr de tester contre undefined. Comme vous l'avez déjà mentionné. Si vous arrivez à un code qui le remplace (ce qui est hautement améliorable), ne l'utilisez plus.

Peut - être que si vous créez une bibliothèque à usage public, vous pouvez utiliser certaines des techniques pour éviter que l'utilisateur ne la modifie. Mais même dans ce cas, c'est leur problème, pas votre bibliothèque.

Vous pouvez utiliser undefineddans votre code lors du codage pour les navigateurs prenant en charge ECMAScript 5.1 car il est immuable selon la spécification du langage .

Voir également ce tableau de compatibilité ou ce caniuse ECMAScript 5 pour voir que tous les navigateurs modernes (IE 9+) ont implémenté immuableundefined .

Ce n'est pas du tout dangereux. Il ne peut être écrasé que lors de l'exécution sur un moteur ES3 et il est peu probable que ce soit plus utilisé.

Tout d'abord, si votre code casse, ce n'est probablement pas parce qu'un autre développeur "essaie d'être un imbécile" comme vous le dites.

C'est vrai que ce undefinedn'est pas un mot-clé. Mais il est un niveau mondial primitif. Il était destiné à être utilisé comme ceci (voir "non défini" sur developer.mozilla.org ):

var x;
if (x === undefined) {
    // these statements execute
}
else {
    // these statements do not execute
}

L'alternative commune à cela (également de MDN ) et à mon avis la meilleure façon est:

// x has not been declared before
if (typeof x === 'undefined') { // evaluates to true without errors
    // these statements execute
}

if(x === undefined){ // throws a ReferenceError

}

Ce qui présente quelques avantages, le plus évident (d'après les commentaires) est qu'il ne déclenche pas d'exception lorsque x n'est pas déclaré. Il convient également de noter que MDN souligne également qu'il est important d'utiliser ===over ==dans le premier cas car:

var x=null;
if (x === undefined) {
    // this is probably what you meant to do
    // these lines will not execute in this case
}
else if (x == undefined) {
    // these statements will execute even though x *is* defined (as null)
}
else {
    // these statements do not execute
}

C'est une autre raison souvent négligée pour laquelle il est probablement préférable d'utiliser simplement la deuxième alternative dans tous les cas.

Conclusion: il n'est pas faux de le coder de la première manière, et certainement pas dangereux. L'argument que vous avez vu que vous utilisez comme exemple contre lui (qu'il peut être écrasé) n'est pas l'argument le plus fort pour coder l'alternative avec typeof. Mais l'utilisation typeofest plus forte pour une raison en particulier: elle ne lève pas d'exception lorsque votre var n'est pas déclarée. On pourrait également faire valoir que l'utilisation ==au lieu de ===est une erreur courante, auquel cas elle ne fait pas ce que vous attendiez. Alors pourquoi ne pas l'utiliser typeof?