Javascript: est-il dangereux de supposer qu'un non défini n'est pas écrasé?

Question

Chaque fois que quelqu'un mentionne l'essai contre undefined, il est à souligner que l' undefined n'est pas un mot-clé, de sorte qu'il peut être réglé en "hello", de sorte que vous devez utiliser typeof x == "undefined" à la place. Cela semble ridicule pour moi. Personne ne serait jamais le faire, et si ils l'ont fait serait une raison suffisante pour ne jamais utiliser le code écrit... droit?

J'ai trouvé un exemple de quelqu'un qui accidentelle undefined de null, ce qui a été donné comme raison de ne pas assumer qu' undefined n'est pas écrasé. Mais s'ils avaient fait cela, le bug aurait été détectée, et je ne vois pas en quoi c'est mieux.

En C++ tout le monde est bien conscient qu'il est légal de le dire #define true false, mais personne n'a jamais vous conseille d'éviter true et l'utilisation 0 == 0 à la place. Vous simplement supposer que personne ne sera jamais assez grand branler pour le faire, et s'ils le font, ne jamais faire confiance à leur code de nouveau.

A ce jamais mordu quelqu'un où quelqu'un d'autre attribué undefined (sur le but) et il a cassé votre code, ou est-ce plus d'une hypothétique menace? Je suis prêt à prendre mes chances de faire de mon code un peu plus lisible. Personne ne pense que c'est vraiment une mauvaise idée?

EDIT: Pour rappel, je suis pas demandant comment se protéger contre les réaffectés pas défini. J'ai vu de ces trucs écrit 100 fois déjà. Je me demande combien il est dangereux de ne pas utiliser ces trucs.

Answer 1

Non, je n'ai jamais. C'est surtout parce que je développe sur les navigateurs modernes, qui sont pour la plupart ECMAScript 5 conforme. L'ES5 norme dicte qu' undefined est maintenant en lecture seule.

Si vous êtes inquiet au sujet de code externe à l'écrasement undefined, vous pouvez toujours faire ceci:

var undefined = 15; // Haha! I am malicious!

(function(undefined) {
    var x;

    alert(x === undefined); // Curses, foiled again!
})();

et il ne sera pas de mal, sauf si vous les remplacez. Beaucoup plus lisible qu' typeof, et vous pouvez également restreindre l' 'use strict'; de votre script, même lorsque les scripts sont combinés.

Ne jamais le faire. Vous ne devriez jamais avoir à être inquiet à ce sujet. Rendant undefined d'un argument d'une IIFE est plus sujette à l'erreur. Code en mode strict, utiliser un décent navigateur de développement, d'exécuter des linters à l'encontre de votre code, et immédiatement jeter toute bibliothèque qui essaie d'écraser undefined.

Answer 2

Pas de code faire une telle chose. Mais vous ne pouvez jamais savoir ce que certains wannabe-smart développeur ou un plugin/bibliothèque/script que vous utilisez n'. De l'autre côté, il est extrêmement peu probable et les navigateurs modernes ne permettra pas de les écraser undefined à tous, donc si vous êtes en utilisant par exemple un navigateur pour le développement vous remarquerez rapidement si le code tente de l'écraser.

---

Et même si vous n'avez pas demander pour elle - beaucoup de gens vont probablement trouver cette question lors de la recherche pour le plus commun "comment se protéger contre les redéfini undefined" question, donc je vais répondre à ça de toute façon:

Il existe un très bon moyen d'obtenir un vraiment l' indéfini undefined n'importe comment vieux le navigateur est:

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

Cela fonctionne parce que l'argument n'est pas spécifié est toujours undefined. Vous pouvez aussi le faire avec une fonction qui accepte des arguments réels, par exemple, comme cela, lorsque vous êtes à l'aide de jQuery. C'est généralement une bonne idée d'assurer un environnement sain de cette façon:

(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 remplies:

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

---

Toutefois, notez que, parfois, typeof x === 'undefined' est réellement nécessaire: Si la variable x n'a jamais été définie à une valeur (par opposition à être mis à l' undefined), la lecture, x d'une manière différente comme if(x === undefined) lèvera une erreur. Cela ne s'applique pas aux propriétés de l'objet, si vous savez qu' y est toujours un objet, if(y.x === undefined) est parfaitement sûr.

Answer 3

Il existe une solution simple à cela: comparez contre void 0 qui est toujours indéfini.

Notez que vous devriez éviter == car cela pourrait 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 == en comparant quelque chose avec undefined .

Answer 4

Seulement, vous savez quel est le code que vous utilisez, et par conséquent combien il est dangereux. Cette question ne peut pas être la réponse que vous avez précisé que vous souhaitez qu'il a répondu.

1) Créer une équipe la politique, de rejeter la redéfinition pas défini, le réservant pour son plus populaires utilisation. Scannez votre code existant pour non-défini gauche d'une affectation.

2) Si vous n'avez pas le contrôle de tous les scénarios, si votre code est utilisé en dehors de situations, vous ou vos politiques de contrôle, alors évidemment, votre réponse est différente. Scannez le code qui n'utilise vos scripts. Heck, d'analyse web de statistique de indéfini à gauche de l'assignation si vous le souhaitez, mais je doute que c'est fait pour vous, parce que c'est plus facile de poursuivre une réponse #1 ou #3 ici à la place.

3) Et si cette réponse n'est pas assez bon, c'est probablement parce que, encore une fois, vous avez besoin d'une réponse différente. Peut-être que vous écrivez un populaire bibliothèque qui sera utilisé à l'intérieur du pare-feu, et vous n'avez pas accès au code appelant. Puis utilisez l'une de l'autre fine des réponses ici. Note le populaire bibliothèque jQuery pratiques de son encapsulation, et commence:

(function( window, undefined ) {

Vous seul pouvez répondre à votre question dans la manière spécifique que vous cherchez. Quoi de plus est-il à dire?

edit: p.s. si vous voulez vraiment mon avis, je vais vous dire que c'est pas dangereux du tout. Tout ce qui serait donc susceptible d'entraîner des défauts (comme l'affectation de undefined, ce qui est évidemment bien documentée des comportements à risque) est lui-même un défaut. C'est le défaut qui est le risque. Mais c'est juste dans mes scénarios, où je peux me permettre de tenir ce point de vue. Comme je vous recommande de le faire, j'ai répondu à la question pour mon cas d'utilisation.

Answer 5

Il est prudent de tester contre indéfini. Comme tu le dis déjà. Si vous rencontrez 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 pour un usage public, vous pouvez utiliser certaines des techniques pour éviter que l'utilisateur ne la change. Mais même dans ce cas, c'est leur problème, pas votre bibliothèque.