javascript qtip

Asignando primitivas de JavaScript a su variable equivalente nombrada como "constantes"



qtip position (3)

Estaba mirando el código fuente de qTip 2 y vi lo siguiente:

// Munge the primitives - Paul Irish tip var TRUE = true, FALSE = false, NULL = null;

No puedo encontrar una razón por la que debas hacer esto, y tengo la fuerte sensación de que solo alentaría malos hábitos de codificación. Supongamos que un desarrollador hace un error tipográfico en una condición de Yoda como if (TRUE = someCondition()) , entonces TRUE podría muy bien significar false , o podría terminar asignando someObject a NULL .

Supongo que solo me pregunto si hay alguna cualidad de redención para esta práctica que me estoy perdiendo, o si esto es solo una vieja y mala idea.


Creo que esto se recomienda para la compresión.

Estas variables de acceso directo se comprimirán cuando se combinen, lo que dará como resultado archivos más pequeños. Sin embargo, sus inconvenientes señalados son sin duda puntos válidos!


El objetivo de esto es simplemente mejorar la compresión, el propio Paul Irish lo llama "Anti-Pattern".

Lo describe como "Bueno para la compresión y el alcance de la cadena de alcance" en la siguiente presentación:

En el recorrido de la cadena de alcance, no veremos ninguna mejora en los literales como null , false , true , ya que la cadena de alcance no se inspecciona, son solo literales.

En otros identificadores como undefined o windows el recorrido de la cadena de alcance se inspecciona.


Usted podría hacer esto por el bien de la compresión de código. Por ejemplo, YUI Compressor no tocará true o false , pero podría reemplazar todas las apariciones de, por ejemplo, TRUE con A , ahorrando cuatro caracteres por suceso. Por ejemplo, antes de la compresión:

if (foo === null) { bar = true; }

Después de la compresión, asumiendo que el compresor reemplaza TRUE con a y NULL con c :

if(foo===c){bar=a;}

Frente a esto, después de la compresión sin "mezcla de primitivas":

if(foo===null){bar=true;}

El peligro de los malos hábitos de codificación que usted cita correctamente en su pregunta puede superar los pequeños ahorros en compresión adicional. Depende de lo desesperado que estés para salvar algunas docenas o quizás unos cientos de bytes.

Personalmente, yo ( casi ) nunca haría esto. Demasiado peligroso.