¿Cuáles son los peores hábitos de programación en Javascript?

Airbnb abrió su guía de estilo de JavaScript ideal que recibió ~ 60k GitHub protagoniza airbnb / javascript. En la guía, propuso la forma ideal de escribir JavaScript y para cada ejemplo, da una mala y luego la buena. Aquí están los que personalmente me gustaron,

Siempre debes tratar de no mutar tu matriz original. En su lugar, haga una copia y modifique la nueva. (Prefiere el operador de propagación de objetos sobre Object.assign)

Aquí, hablé sobre objeto mutable vs inmutable en JavaScript.

// muy mal
const original = {a: 1, b: 2};
const copy = Object.assign (original, {c: 3}); // esto muta `original` ಠ_ಠ

// bueno
const original = {a: 1, b: 2};
const copia = {… original, c: 3}; // copia => {a: 1, b: 2, c: 3}

Nunca debe citar sus propiedades clave a menos que incluya un identificador no válido, por ejemplo, “-“.

// malo
const bad = {
‘foo’: 3,
‘bar’: 4,
‘datos-bla’: 5,
};

// bueno
const good = {
foo: 3,
bar: 4,
‘datos-bla’: 5,
};

Siempre intente usar Array.push en lugar de la asignación directa para agregar elementos a una matriz. (La asignación directa es una idea muy mala ya menudo conduce a un comportamiento / error extraño en el futuro)

const someStack = [];

// malo
someStack [someStack.length] = ‘abracadabra’;

// bueno
someStack.push (‘abracadabra’);

Para más ejemplos, visite airbnb / javascript

¡Espero que esto ayude!

Crear literales de objetos que representan un “tipo” particular en todo el lugar, en lugar de usar una sola fábrica para crear todas las instancias (desde los parámetros pasados ​​a esa fábrica). JavaScript fomenta este tipo de enfoque literal al hacer que la creación de instancias de esta manera sea tan fácil. Y simplemente funciona. Pero tiene varias desventajas, tales como:

  1. Si, más adelante, desea cambiar la estructura de este “tipo”, tendrá que buscar en todo el código para encontrar todas las ubicaciones donde se creó. Y dado que probablemente no haya una indicación específica para esto, es probable que se pierda un par.
  2. Si el orden de propiedad en las instancias literales no es idéntico, el código seguirá funcionando pero será mucho menos eficiente. Esto se debe a que el compilador de JavaScript no podrá crear una “clase oculta” común para instancias con diferente orden de propiedad.

He visto este tipo de anti-patrón en varias aplicaciones de JavaScript.

escriba ‘==’ en lugar de ‘===’ en condiciones lógicas.

Por lo general, usamos ‘==’ en javascript para verificar si es igual en ambos lados (al menos eso es lo que vi en algunas personas, y no entienden por qué la función no funciona como se esperaba).

Son similares, pero algo diferentes.

Ejemplo 1:

1 == 1 → VERDADERO

1 === 1 → VERDADERO

Ejemplo 2:

1 == VERDADERO → VERDADERO

1 === VERDADERO → FALSO

Lo malo de javascript es que solo tiene “var” para la declaración, pero no una declaración de tipo de datos. En el ejemplo de “==”, ambos ejemplos devuelven VERDADERO porque “==” devuelve verdadero si ambos valores son iguales de alguna manera (s) [Cualquier valor mayor que 0 en entero también puede considerarse VERDADERO en booleano]. Sin embargo, “===” verifica si ambos valores son exactamente iguales, por eso 1 === TRUE es FALSE.

Entonces, si no hay nada especial, siempre use “===” para la comprobación exacta.

( Me avergüenzo de encontrar este medio año antes, dado que escribo javascript por un litro mientras … )

Errores que se aplican a muchos lenguajes de programación:

¿Cuáles son los peores hábitos de programación en Javascript?

1) Escribir funciones demasiado grandes

2) No escribir funciones que conduzcan a un código de espagueti.

3) Tener demasiadas funciones en las funciones en el mismo módulo (por ejemplo, un controlador demasiado grande en Angular es una mala práctica, debe escribir el código de negocio en un servicio)

4) No usar JQuery, Reaccionar o Angular … No debes reinventar la rueda, la vida es demasiado corta, no tienes tiempo

5) No prueba el código

6) No utilizar la programación funcional propuesta por javascript cuando podría (expl: mapear, reducir, filtrar, cada, cada …)

7) No usar algunas sintaxis limpias como:
if (x) {…} // el if se considera verdadero si x es diferente de indefinido, cadena vacía y 0 …

Me pasa a mi Y se dio un largo tiempo de depuración y al final lo que tenemos es un error tonto.

En realidad, quería comprobar si el valor existe y luego ir dentro de la lógica, así que escribí algo como a continuación.

si (myVar) {}

Aquí mi intención era como si myVar tiene algún valor para ir dentro de la condición if. Funcionará bien a menos que el valor venga a 0.

Tienes lo que estaba tratando de decir …

No, entonces cuando el valor 0 viene, la condición if lo trata como booleano. Y en Booleano 0 significa falso, así que siempre que viene 0 mi lógica se rompe. En ese momento aprendí una lección, siempre trate de verificar el tipo de variable.

Así que para superar ese problema reescribí la condición como abajo

if (myVar || typeof myVar! = undefined)

Gracias por leer.

Feliz gente de codificación …

Creo que lo que más me engaña hasta esta fecha es no tener cuidado con la diferencia entre == y ===.

También me han quemado muchas horas de depuración, reduciéndome a solo un carácter en el código; un punto y coma faltante. Sintaxis, está bien, pero funcionalmente no está bien. Sólo una letra en el código!

Siempre usa {j / t} slint. Presta atención a las advertencias.

No colocar un punto y coma después de la línea de código ya que esto puede hacer que se rompa todo el código. Esto puede ser frustrante y llevar a una gran cantidad de depuración inútil.