qué - programacion javascript

¿Qué tan peligroso es en JavaScript, en realidad, suponer indefinido no se sobrescribe?

Question

Cada vez que alguien menciona la prueba como undefined , se señala que undefined no es una palabra clave, por lo que se puede configurar como "hello" , por lo que debe usar typeof x == "undefined" lugar. Esto me parece ridículo. Nadie haría eso, y si lo hicieran, sería motivo suficiente para nunca usar el código que escribieron ... ¿verdad?

Encontré un ejemplo de alguien que accidentalmente definió undefined como null , y esto se dio como una razón para evitar asumir que undefined se sobrescribe undefined . Pero si lo hubieran hecho, el error no habría sido detectado, y no veo cómo es mejor.

En C ++ todo el mundo sabe muy bien que es legal decir #define true false , pero nadie le aconseja evitarlo y usa 0 == 0 lugar. Solo asumes que nadie sería lo suficientemente grande como para hacer eso, y si lo hacen, nunca confíes en su código nuevamente.

¿Esto realmente ha mordido a alguien en el que alguien más ha sido asignado a undefined (a propósito) y rompió su código, o es más una amenaza hipotética? Estoy dispuesto a correr el riesgo de hacer que mi código sea ligeramente más legible. ¿Es esta realmente una mala idea?

Para reiterar, no estoy preguntando cómo proteger contra indefinido reasignado. He visto esos trucos escritos 100 veces. Pregunto qué tan peligroso es no usar esos trucos.

Answer 1

En primer lugar, si tu código se rompe probablemente no sea porque otro desarrollador "está tratando de ser un idiota", como tú lo pones.

Es cierto que undefined no es una palabra clave. Pero es un primitivo de nivel global. Estaba destinado a ser usado así (ver "undefined" en developer.mozilla.org ):

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

La alternativa común a eso (también de developer.mozilla.org ) y en mi opinión la mejor manera es:

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

Lo cual tiene un par de ventajas, la más obvia (de los comentarios) es que no activa una excepción cuando x no está declarado. También vale la pena señalar que MDN también señala que es importante usar === sobre == en el primer caso porque:

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
}

Esta es otra razón que a menudo se pasa por alto por qué es mejor usar la segunda alternativa en todos los casos.

Conclusión: no está mal codificarlo de la primera manera, y ciertamente no es peligroso. El argumento que ha visto que usa como ejemplo en su contra (que puede sobrescribirse) no es el argumento más sólido para codificar la alternativa con typeof . Pero el uso de typeof es más fuerte por una razón específica: no lanza una excepción cuando tu var no está declarada. También podría argumentarse que usar == lugar de === es un error común, en cuyo caso no está haciendo lo que usted esperaba. Entonces, ¿por qué no usar typeof ?

Answer 2

Es seguro probar contra indefinido. Como ya lo mencionas Si llega a algún código que lo anule (que es altamente mejorable), simplemente no lo use más.

Tal vez si está creando una biblioteca para uso público, puede usar algunas de las técnicas para evitar que el usuario la cambie. Pero incluso en este caso, es su problema, no su biblioteca.

Answer 3

Hay una solución simple para eso: comparar contra el void 0 que siempre está indefinido.

Tenga en cuenta que debe evitar == ya que puede forzar los valores. Use === (y !== ) en su lugar.

Dicho esto, la variable indefinida puede establecerse por error si alguien escribe = lugar de == cuando compara algo contra undefined .

Answer 4

Ningún código apropiado hará tal cosa. Pero nunca se puede saber qué hizo algún desarrollador inteligente o un plugin / library / script que esté usando. Por otro lado, es extremadamente improbable y los navegadores modernos no permitirán la sobreescritura undefined en absoluto, por lo que si está utilizando un navegador de este tipo para el desarrollo, notará rápidamente si algún código intenta sobreescribirlo.

Y a pesar de que no lo solicitó, muchas personas probablemente encontrarán esta pregunta cuando busquen el problema más común de "cómo protegerse contra undefined redefinido", así que responderé de todos modos:

Hay una muy buena manera de obtener un indefinido undefined sin importar la antigüedad del navegador:

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

Esto funciona porque un argumento que no se especifica siempre está undefined . También puede hacerlo con una función que acepte algunos argumentos reales, por ejemplo, cuando está utilizando jQuery. Por lo general, es una buena idea garantizar un entorno sano de esta manera:

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

Entonces puede estar seguro de que dentro de esa función anónima las siguientes cosas son verdaderas:

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

Sin embargo, tenga en cuenta que a veces typeof x === ''undefined'' es realmente necesario: si la variable x nunca se ha establecido en un valor (contrario a establecerse en undefined ), leer x de una manera diferente, como if(x === undefined) lanzará un error. Sin embargo, esto no se aplica a las propiedades del objeto, por lo que si sabes que y es siempre un objeto, if(yx === undefined) es perfectamente seguro.

Answer 5

No es peligroso en absoluto. Solo se puede sobrescribir cuando se ejecuta en un motor ES3 y es probable que ya no se use.

Answer 6

No, nunca lo hice. Esto se debe principalmente a que desarrollo en navegadores modernos, que son en su mayoría compatibles con ECMAScript 5. El estándar ES5 dicta que undefined ahora es de solo lectura. Si usa el modo estricto (debería), se producirá un error si accidentalmente intenta modificarlo.

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

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

Lo que no debes hacer es crear tu propio ámbito undefined :

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

Constant está bien. Aún innecesario, pero bien.

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

Answer 7

Puede utilizar undefined en su código cuando codifica navegadores compatibles con ECMAScript 5.1 ya que es inmutable de acuerdo con la especificación del idioma .

También vea this tabla de compatibilidad o this archivo ECMAScript 5 para ver que todos los navegadores modernos (IE 9+) han implementado inmutable undefined .

Answer 8

Solo tú sabes qué código usas y, por lo tanto, qué peligroso es. Esta pregunta no puede responderse de la manera en que usted ha aclarado que quiere que se responda.

1) Cree una política de equipo, no permita redefinir indefinido, reservándolo para su uso más popular. Escanee su código existente para la asignación izquierda indefinida.

2) Si no controla todos los escenarios, si su código se usa fuera de situaciones que usted o sus políticas controlan, obviamente su respuesta es diferente. Escanee el código que usa sus scripts. Diablos, escanee la web en busca de estadísticas de asignaciones izquierdas indefinidas si lo desea, pero dudo que se haya hecho por usted, porque en este caso es más fácil buscar las respuestas n. ° 1 o n. ° 3.

3) Y si esa respuesta no es lo suficientemente buena, es probable que sea porque, de nuevo, necesita una respuesta diferente. Tal vez esté escribiendo una biblioteca popular que se usará dentro de firewalls corporativos, y no tiene acceso al código de llamada. Luego usa una de las otras respuestas finas aquí. Tenga en cuenta que la popular biblioteca jQuery practica la encapsulación de sonido y comienza:

(function( window, undefined ) {

Solo tú puedes responder a tu pregunta de la manera específica que buscas. ¿Qué más hay que decir?

edit: ps si realmente quieres mi opinión, te diré que no es peligrosa en absoluto. Cualquier cosa que pueda causar defectos (como la asignación a indefinido, que obviamente es un comportamiento arriesgado bien documentado) es en sí mismo un defecto. Es el defecto ese el riesgo. Pero eso es solo en mis escenarios, donde puedo permitirme mantener esa perspectiva. Como recomendaría que hicieras, respondí la pregunta para mis casos de uso.