Sintaxis y punto y coma en JavaScript: reglas ASI

El código JavaScript es una secuencia de sentencias

Un programa de JavaScript es una lista de sentencias: instrucciones que el motor ejecuta de arriba abajo. Declarar una variable es una sentencia. Llamar a una función es una sentencia. Un bloque if o un for también lo son. Las sentencias se separan entre sí con punto y coma.

Tres sentencias, tres puntos y coma. El motor ejecuta la primera, luego la segunda y después la tercera. Así de sencillo.

Los espacios y la indentación no le dicen nada al parser. Podrías meter las tres sentencias en una sola línea separadas por punto y coma y funcionaría exactamente igual. Indentamos para que lo leamos los humanos, no para el motor.

Los bloques agrupan sentencias

Las llaves { } forman un bloque: un conjunto de sentencias que el motor trata como una sola unidad. Vas a encontrarte bloques por todas partes: en el cuerpo de funciones, en las ramas de un if y en los cuerpos de los bucles.

Las dos llamadas a console.log dentro de las llaves forman el cuerpo del if. Fíjate que no hay punto y coma después de la llave de cierre }: los bloques no son sentencias que necesiten terminador. La sentencia if completa termina cuando termina el bloque.

Esto pilla desprevenidos a quienes vienen de lenguajes donde cada } pide un ; detrás. En JavaScript, ni un bloque suelto ni un bloque de control de flujo lo necesitan.

Expresiones vs. sentencias

Conviene tener clara esta distinción desde el principio: las expresiones producen un valor, las sentencias hacen algo.

• 2 + 3 es una expresión. Se evalúa a 5.
• let x = 2 + 3; es una sentencia. Declara una variable y le asigna el resultado de una expresión.
• console.log("hi") es una expresión (una llamada a función devuelve undefined), pero al escribirla en su propia línea con un punto y coma se convierte en una sentencia de expresión.

La mayor parte del tiempo no tienes que pensar en esto. Cobra importancia cuando te topas con arrow functions, ternarios y lugares donde JavaScript espera una expresión pero le diste una sentencia (o al revés).

¿Hace falta el punto y coma en JavaScript?

La respuesta honesta es esta: JavaScript tiene una característica llamada Inserción Automática de Punto y Coma (ASI, por sus siglas en inglés) que inserta por ti los puntos y coma que falten en la mayoría de los saltos de línea. Por eso, código como el siguiente funciona sin problemas:

Sin punto y coma, sin errores. El mecanismo de ASI revisa cada salto de línea y se pregunta: "¿podría el siguiente token ser continuación de la sentencia actual?" Si la respuesta es no, inserta un punto y coma.

Gracias a la inserción automática de punto y coma en JavaScript, conviven dos estilos legítimos en el mundo real:

• Siempre con punto y coma. La mayoría de proyectos, tutoriales y guías de estilo lo recomiendan.
• Sin punto y coma. Se usa en algunos proyectos modernos (estilo Standard, ciertas bases de código de React). Se apoya en ASI más un par de trucos defensivos.

Los dos funcionan. Ninguno es "incorrecto". Lo que sí es un problema es la inconsistencia: mezclar estilos dentro del mismo archivo hace que los bugs sean mucho más difíciles de detectar.

Cuándo ASI te juega una mala pasada

ASI hace lo correcto el 99% de las veces. Ese 1% restante son las líneas que empiezan con un token que podría continuar la línea anterior. Los sospechosos habituales son [, (, `, +, - y /.

Fíjate en este caso:

Uno esperaría que x y y se intercambiaran. Pero no: el ASI no inserta punto y coma antes de [x, y], porque 10[x, y] es sintácticamente válido (sería indexar sobre el número 10). El parser se come la línea 2 y la línea 3 como si fueran una sola expresión, y acabas con un error en tiempo de ejecución o con basura por salida.

La solución pasa por poner punto y coma al final de la línea 2:

O, si escribes en estilo sin punto y coma, pon un punto y coma al principio de la línea problemática:

Ese ; al principio es el truco defensivo que usan los proyectos sin punto y coma. Parece raro hasta que entiendes para qué está.

La trampa del return

Hay un caso de ASI que conviene memorizar, porque genera bugs silenciosos. Si metes un salto de línea justo después de return, ASI coloca ahí un punto y coma y la función acaba devolviendo undefined:

El autor quería devolver un objeto. ASI vio return al final de la línea y cerró la sentencia ahí mismo. El objeto literal quedó como código inalcanzable.

La solución es empezar el valor en la misma línea que return:

La misma regla se aplica a throw, break, continue y yield: no metas un salto de línea entre la palabra clave y su valor.

Una regla sencilla que funciona

Si estás empezando, lo más práctico es esto:

1. Escribe el punto y coma de forma explícita al final de cada sentencia.
2. No lo pongas después de una } que cierra un bloque de if, for, while, declaraciones de función o cuerpos de clase.
3. Sí ponlo después de } cuando se trate de un objeto literal o una expresión de función asignada a una variable: const f = function() {};.
4. Usa un formateador (Prettier, o ESLint con una regla de estilo) y olvídate del tema. El formateador aplica lo que tu equipo haya decidido.

Esta regla no es una ley universal, sino la convención que vas a encontrar en la mayoría del código JavaScript que leas. Síguela hasta que tengas una buena razón para no hacerlo.

Sensibilidad a mayúsculas e identificadores

Dos reglas pequeñas que también entran aquí:

• JavaScript distingue entre mayúsculas y minúsculas. userName, username y UserName son tres identificadores distintos.
• Los identificadores pueden contener letras, dígitos, _ y $, pero no pueden empezar por un dígito. Tampoco pueden ser palabras reservadas como class, return o function.

El símbolo $ es válido, pero por convención suele reservarse para cosas específicas de librerías (jQuery lo usó históricamente, y algunos sistemas de plantillas lo siguen usando). Rara vez lo eliges tú.

Siguiente: Modo estricto

El JavaScript moderno corre, sin hacer ruido, en una variante más rigurosa del lenguaje llamada modo estricto, que convierte un puñado de comportamientos laxos en errores reales. Los módulos ES y el cuerpo de las clases son estrictos por defecto, pero vale la pena saber qué cambia exactamente — de eso trata la siguiente página.