EcmaScript 6

1. Añadir saltos de línea donde no corresponde

JavaScript en ocasiones añade el ";" de forma explicita cuando hay un salto de línea. Si no tenemos cuidado con esto, puede haber comportamientos no esperados en nuestra aplicación. Es por ello que se aconseja evitar, tanto partir líneas en algunos casos, como abrir las llaves en la línea siguiente. En el siguiente ejemplo de CodePen (sí por fin me hice una cuenta 😛), podéis ver lo que ocurre:

Como se puede ver en el ejemplo tenemos un return de una cadena, y en el primer caso hemos movido a la cadena. Esto que puede parecer que a todas luces nos devolverá la cadena, en realidad lo que hará es devolver undefined. Lo que ha hecho JavaScript en este caso, es poner un ; junto a la sentencia return.

2. No usar bucles for...of

Siempre que puedas, comienza a utilizar los nuevos bucles for...of, ya que ofrecen mucho más rendimiento. En el siguiente código, hemos definido dos funciones. Una de ellas hace un recorrido con un for tradicional, y la seguna con un for...of. Para igualar el comportamiento, en la función que usa el for...of hemos incluído una variable que actúa como contador (aunque no hace falta), pero así se tendremos la misma "lógica" en ambas funciones.

Como se puede ver, la diferencia del tiempo de ejecución entre un bucle y el otro, es abismal.

3. Usar == y !=, en lugar de === y !==

Seguramente, esta te sonará. Y es que, a no ser que partas de un lenguaje tipado como TypeScript, el usar un == puede dar algún quebradero de cabeza. El uso de los operadores == y != compara el valor de cada variable y realiza un casting a otro tipo de dato si fuera necesario. Por el contrario, los operadores === y !== aparte del valor, verifican que el tipo de dato sea el mismo.

// El código que viene a continuación en el mundo real no tendría sentido, pero nos sirve para
// ilustrar el comportamiento.

const result = 123.456;
const expected = "123.456";

// En este caso, el código saltará al else, porque estamos comparando tanto el valor como el tipo de dato.
if (result === expected) {
  // Por aquí no entrará.
} else {
  // Por aquí sí.
}

if (result == expected) {
    // Hemos supuesto que al ser iguales los valores (sin validad el tipo), expected almacena un número,
    // pero lo que hará es provocar la excepción: TypeError: expected.toFixed is not a function.
    let fixed = expected.toFixed(1);
}

En el código superior se usa un ejemplo bastante poco real, pero nos puede servir para ver los tipos de problemas que pueden surgir por el uso de ==.

4. Seguir usando funciones para definir las clases

A no ser que tengas que hacer desarrollos para un navegador como IE (por tu bienestar mental, espero que no sea así). Deberías comenzar a usar la definición nativa de clases en JavaScript.

class Personaje {
  #vida;
  #ataque;

  constructor(vidaInicial, ataqueInicial) {
    this.#vida = vidaInicial;
    this.#ataque = ataqueInicial;
  }

  mover() {
    ...
  }

  #puedeMoverse() {
    ...
  }
}

La nueva sintaxis de JavaScript para definición de clases te proporciona un estilo mucho más próximo a lo que puedes ver en otros lenguajes de programación, así que olvídate de prototype y demás elementos extraños. Puedes aprender más sobre esta sintaxis de JavaScript en la serie de artículos Orientación a objetos con JavaScript.

5. Usar var en lugar de let y const

¿Aún defines tus variables con var? ¿Aunque nunca vayan a cambiar su valor? Pues bien, para evitar los problemas de hoisting, o que alguien modifique lo que pensabas que era una constante, o que pienses que una variable se encontraba en un ámbito acotado y es global; puedes usar let y const.

function letYConst(parametro) {
  let variableGlobalALaFuncion;
  const constanteNoSePuedeCambiar = 123;

  // Si ahora escribiéramos:
  // constanteNoSePuedeCambiar = 345;
  // tendríamos un error.

  if (parametro) {
    let variableConAmbitoDeIf = true;
  }

  // Si ahora intentamos llamar a variableConAmbitoDeIf, tendríamos un error.
}

Puedes ver más información sobre las diferencias entre let y var en este artículo.


Y con esto hemos terminado este breve artículo. ¿Qué más cosas se os ocurren que no se deberían hacer en JavaScript? ¿Conocías alguna de las alternativas propuestas para evitarlas?

Como siempre dejad vuestros comentarios y nos vemos en el próximo artículo.

Comparte este artículo con quien quieras
Principios SOLID. Capítulo D: Dependency Inversion Principle
Clases vs Clases abstractas vs Interfaces

Leave a Comment

Your email address will not be published. Required fields are marked *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.