javascript anti-patterns

¿Qué anti patrones existen para JavaScript?



anti-patterns (10)

No utilizar un marco basado en la comunidad para realizar tareas repetitivas como la manipulación de DOM, el manejo de eventos, etc.

Encuentro que lo que no se debe hacer es una lección más difícil de aprender que lo que se debe hacer.

Desde mi experiencia, lo que separa a un experto de un intermediario es la capacidad de seleccionar entre varias formas aparentemente equivalentes de hacer lo mismo.

Entonces, cuando se trata de JavaScript, ¿qué tipo de cosas no debes hacer y por qué ?

Puedo encontrar muchos de estos para Java, pero dado que el contexto típico de JavaScript (en un navegador) es muy diferente al de Java, tengo curiosidad por ver qué sale.

Además de los ya mencionados ...

  • Usando el constructo for..in para iterar sobre matrices
    (itera sobre los métodos e índices de la matriz)

  • Usando Javascript en línea como <body onload="doThis();">
    (inflexible y evita múltiples oyentes de eventos)

  • Usando el constructor ''Function ()''
    (Malo por las mismas razones eval() es malo)

  • setTimeout cadenas en lugar de funciones para setTimeout o setInterval
    (también usa eval() internamente)

  • Confiando en declaraciones implícitas al no usar punto y coma
    (mal hábito de recoger, y puede conducir a un comportamiento inesperado)

  • Usando / * .. * / para bloquear líneas de código
    (puede interferir con los literales de /* /.*/ */ regulares, por ejemplo: /* /.*/ */ )

    <evangelismo> Y, por supuesto, no usar Prototipo;) </ evangelismo>

cualquier referencia a

document.all

en su código, a menos que esté dentro de un código especial, solo para que IE supere un error de IE. ( tos document.getElementById () tos )

cualquier uso de ''con''

con (document.forms ["mainForm"]. elementos) {
input1.value = "basura";
input2.value = "basura"; }

  • detección de navegador (en lugar de probar si existen los métodos / campos específicos que desea usar)
  • usando alerta () en la mayoría de los casos

vea también "Javascript: The Good Parts" de Crockford para otras cosas que debe evitar. ( Editar: advertencia, él es un poco estricto en algunas de sus sugerencias, como el uso de "===" sobre "==", así que tómalo con el grano de sal que funcione para ti)

Lo más importante para mí es no entender el lenguaje de programación JavaScript en sí.

  • Uso excesivo de jerarquías de objetos y construcción de cadenas de herencia muy profundas. Las jerarquías superficiales funcionan bien en la mayoría de los casos en JS.
  • No entiende la orientación de objetos basada en prototipos, y en su lugar crea enormes cantidades de andamios para hacer que JS se comporte como los lenguajes OO tradicionales.
  • Usar innecesariamente paradigmas OO cuando la programación procedimental / funcional podría ser más concisa y eficiente.

Luego están aquellos para el tiempo de ejecución del navegador:

  • No se utilizan buenos patrones de eventos establecidos como la delegación de eventos o el patrón del observador (pub / sub) para optimizar el manejo de eventos.
  • Haciendo frecuentes actualizaciones DOM (como .appendChild en un bucle), cuando los nodos DOM pueden estar en la memoria y anexados de una vez. (ENORME beneficio de rendimiento).
  • Uso excesivo de bibliotecas para seleccionar nodos con selectores complejos cuando se pueden usar métodos nativos (getElementById, getElementByTagName, etc.). Esto se está convirtiendo en un problema menor en estos días, pero vale la pena mencionarlo.
  • Extendiendo objetos DOM cuando esperas que los scripts de terceros estén en la misma página que el tuyo (terminarás peleándose el código del otro).

Y finalmente los problemas de implementación.

  • No minifica tus archivos.
  • Configuraciones del servidor web: no descomprime tus archivos, no los almacena en caché con sensatez.

<complemento> Tengo algunos consejos de optimización del lado del cliente que cubren algunas de las cosas que he mencionado anteriormente, y más, en mi blog. </ plug>

Idioma:

  • Espacio de nombres contaminando al crear una gran huella de variables en el contexto global.

  • Vincula los controladores de eventos en la forma ''foo.onclick = myFunc'' (inextensible, debe estar usando attachEvent / addEventListener).

  • Usar eval en casi cualquier contexto no JSON

  • Casi todos los usos de document.write (use los métodos DOM como document.createElement)

  • Prototipado contra el objeto Objeto (BOOM!)

  • Esto es pequeño, pero hacer un gran número de concatenaciones de cuerdas con ''+'' (crear una matriz y unirlas es mucho más eficiente)

  • En referencia a la constante undefined inexistente

Diseño / Despliegue:

  • (En general) no proporciona soporte de noscript.

  • No empaque su código en un solo recurso

  • Poner scripts en línea (es decir, cuerpo) cerca de la parte superior del cuerpo (bloquean la carga)

Ajax específico:

  • no indica el inicio, el final o el error de una solicitud al usuario

  • votación

  • pasar y analizar XML en lugar de JSON o HTML (cuando corresponda)

editar: ¡sigo pensando en más!

Mal uso del posicionamiento del corsé al crear declaraciones

Siempre debe colocar un refuerzo después de la instrucción debido a la inserción automática de punto y coma.

Por ejemplo esto:

function() { return { price: 10 } }

difiere mucho de esto:

function(){ return{ price: 10 } }

Como en el primer ejemplo, javascript insertará un punto y coma para que realmente te deje con esto:

function() { return; // oh dear! { price: 10 } }

Usando setInterval para tareas potencialmente largas.

Debe usar setTimeout en lugar de setInterval para ocasiones en las que necesite hacer algo repetidamente.

Si usa setInterval, pero la función que se ejecuta en el temporizador no está terminada para el momento en que el temporizador marca el siguiente, esto es malo. En su lugar, use el siguiente patrón usando setTimeout

function doThisManyTimes(){ alert("It''s happening again!"); } (function repeat(){ doThisManyTimes(); setTimeout(repeat, 500); })();

Esto lo explica muy bien Paul Irish en sus 10 cosas que aprendí del video fuente de jQuery

El almacenamiento en caché efectivo casi nunca se realiza:

  • No almacene una copia de la biblioteca (jQuery, Prototype, Dojo) en su servidor cuando puede usar una API compartida como la API de bibliotecas de Google para acelerar las cargas de página.
  • Combina y minimiza todo tu script que puedas en un solo
  • Usa mod_expires para dar a tus scripts una vida útil ilimitada (nunca volver a descargar)
  • Versión sus nombres de archivo de JavaScript para que los clientes tengan una nueva actualización sin necesidad de volver a cargar / reiniciar (es decir, myFile_r231.js o myFile.js? R = 231)

Algunas cosas justo encima de mi cabeza. Editaré esta lista cuando pienso en más.

  • No contamine el espacio de nombre global. Organiza cosas en objetos;
  • No omita ''var'' para las variables. Eso contamina el espacio de nombres global y puede provocar problemas con otras secuencias de comandos.