Formateo de Código JavaScript: Herramientas y Estándares

Abre cualquier pull request donde la mitad del diff sean cambios de espacios en blanco y sentirás el dolor de inmediato. Las inconsistencias de formato desperdician tiempo, ensucian las revisiones de código y generan conflictos de merge que no tienen nada que ver con la lógica. La solución es sencilla: elige un estándar de formato, automatiza su cumplimiento y no vuelvas a pensar en ello.

Esta guía recorre las herramientas y estándares que convierten el formateo de JavaScript en un problema resuelto.

Por qué importa un formato consistente

El formateo no es cuestión de estética, sino de velocidad del equipo. Cuando cada desarrollador usa distinta indentación, colocación de llaves y longitud de línea, ocurren tres cosas:

Las revisiones de código se ralentizan. Los revisores gastan energía mental interpretando un formato desconocido en lugar de evaluar la lógica. Una función que se ve diferente al resto del código base llama la atención por las razones equivocadas.

Los conflictos de merge se multiplican. El desarrollador A reformatea un archivo con tabulaciones, el desarrollador B usa espacios, y ahora Git muestra cada línea como modificada. La corrección real de tres líneas queda sepultada.

La carga cognitiva aumenta. Alternar entre archivos con estilos diferentes obliga a tu cerebro a re-interpretar la estructura constantemente. Un formato consistente te permite leer código como prosa: tus ojos saben exactamente dónde mirar.

La solución no es discutir cuál estilo es mejor, sino elegir uno y automatizarlo.

Guías de estilo populares de JavaScript

Antes de elegir herramientas, conviene conocer las principales guías de estilo que moldearon las convenciones de formato en JavaScript.

Airbnb Style Guide

La guía de estilo de JavaScript más adoptada. Exige punto y coma, prefiere comillas simples, requiere comas finales en construcciones multilínea y usa indentación de 2 espacios. La configuración de ESLint (eslint-config-airbnb) agrupa cientos de reglas que cubren tanto formato como calidad de código.

// Estilo Airbnb
const getUserData = (userId) => {
  const user = findUser(userId);
  return {
    name: user.name,
    email: user.email,
  };
};

Standard Style

Adopta el enfoque opuesto con los punto y coma: ninguno, nunca. Usa indentación de 2 espacios y comillas simples. El paquete standard incluye su propio linter, por lo que no necesitas una configuración de ESLint aparte.

// Estilo Standard
const getUserData = (userId) => {
  const user = findUser(userId)
  return {
    name: user.name,
    email: user.email
  }
}

Google Style Guide

Similar a Airbnb, pero con algunas diferencias en los requisitos de JSDoc y convenciones de nomenclatura. Usa indentación de 2 espacios, requiere punto y coma y prefiere comillas simples.

Cada una de estas guías de estilo tiene sus ventajas y desventajas. Lo importante es la consistencia, no cuál elijas. Y cada vez más, los equipos evitan el debate por completo dejando que Prettier decida.

Prettier: El formateador con opinión

Prettier transformó el formateo de JavaScript al eliminar la mayoría de las decisiones. Parsea tu código en un AST (Abstract Syntax Tree) y lo reescribe según sus propias reglas. No configuras opciones de formato individuales: defines unas pocas opciones generales y Prettier se encarga del resto.

Instalación

npm install --save-dev prettier

Crea un archivo de configuración .prettierrc:

{
  "printWidth": 80,
  "tabWidth": 2,
  "useTabs": false,
  "semi": true,
  "singleQuote": true,
  "trailingComma": "all",
  "bracketSpacing": true,
  "arrowParens": "always"
}

Opciones de configuración clave

printWidth (por defecto: 80) — La longitud de línea donde Prettier hace saltos de línea. No es un límite estricto: Prettier lo usa como referencia para decidir cuándo dividir expresiones en varias líneas. Configurarlo en 100 o 120 es habitual en equipos con monitores anchos.

semi (por defecto: true) — Si se añaden punto y coma al final de las sentencias. Establécelo en false si prefieres el estilo Standard.

singleQuote (por defecto: false) — Usa comillas simples en lugar de comillas dobles. La mayoría de los desarrolladores JavaScript prefieren comillas simples, lo que hace que true sea la configuración más común.

trailingComma (por defecto: "all") — Añade comas finales donde sea válido. Esto produce diffs de Git más limpios, porque agregar un nuevo elemento a una lista solo muestra una línea modificada en vez de dos.

// Sin comas finales — agregar "d" cambia dos líneas
const items = [
-  "a",
-  "b",
-  "c"
+  "a",
+  "b",
+  "c",
+  "d"
];

// Con comas finales — agregar "d" cambia una línea
const items = [
  "a",
  "b",
  "c",
+  "d",
];

arrowParens (por defecto: "always") — Si se envuelve en paréntesis un parámetro único de función flecha. "always" significa (x) => x, "avoid" significa x => x.

Ejecutar Prettier

# Formatear todos los archivos
npx prettier --write .

# Verificar sin modificar
npx prettier --check .

# Formatear tipos de archivo específicos
npx prettier --write "src/**/*.{js,jsx,ts,tsx}"

Añade un archivo .prettierignore para omitir archivos generados:

node_modules
dist
build
coverage
*.min.js

Si trabajas con JavaScript minificado, nuestro Code Minifier se encarga de la minificación correctamente — nunca edites código minificado a mano.

ESLint: Más allá del formato

ESLint cumple un propósito distinto al de Prettier. Mientras Prettier se ocupa de cómo se ve el código, ESLint detecta cómo se comporta. Las reglas de ESLint se dividen en dos categorías:

Reglas de formato — indentación, espaciado, colocación de llaves. Estas se solapan con Prettier y generalmente deben desactivarse cuando se usan ambas herramientas.

Reglas de calidad de código — variables sin usar, código inalcanzable, coerción de tipos implícita, manejo de errores ausente. Aquí es donde ESLint brilla.

Configuración recomendada

npm install --save-dev eslint @eslint/js

Un eslint.config.js mínimo:

import js from '@eslint/js';

export default [
  js.configs.recommended,
  {
    rules: {
      'no-unused-vars': 'warn',
      'no-console': 'warn',
      'eqeqeq': 'error',
      'no-implicit-coercion': 'error',
    },
  },
];

Para proyectos TypeScript, añade typescript-eslint:

npm install --save-dev typescript-eslint

import js from '@eslint/js';
import tseslint from 'typescript-eslint';

export default tseslint.config(
  js.configs.recommended,
  ...tseslint.configs.recommended,
);

Integración de Prettier + ESLint

Ejecutar ambas herramientas sin coordinación genera conflictos: las reglas de formato de ESLint chocan con la salida de Prettier. La solución es eslint-config-prettier, que desactiva todas las reglas de ESLint que entran en conflicto con Prettier.

npm install --save-dev eslint-config-prettier

import js from '@eslint/js';
import prettierConfig from 'eslint-config-prettier';

export default [
  js.configs.recommended,
  prettierConfig,
  {
    rules: {
      // Solo reglas de calidad de código aquí
      'no-unused-vars': 'warn',
      'eqeqeq': 'error',
    },
  },
];

Con esta configuración, Prettier se encarga del formato y ESLint de la calidad del código. Sin conflictos, sin confusión.

EditorConfig para consistencia entre editores

No todos en tu equipo usan el mismo editor. EditorConfig proporciona una base común que funciona en VS Code, WebStorm, Vim, Sublime Text y la mayoría de los demás editores.

Crea un archivo .editorconfig en la raíz de tu proyecto:

root = true

[*]
indent_style = space
indent_size = 2
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true

[*.md]
trim_trailing_whitespace = false

EditorConfig se encarga de lo básico — indentación, finales de línea, espacios en blanco finales — antes de que Prettier siquiera se ejecute. Esto previene el problema común de que un desarrollador en Windows introduzca finales de línea \r\n en un proyecto basado en Unix.

Git Hooks con Husky y lint-staged

El formateo automatizado solo funciona si realmente se ejecuta. Depender de que los desarrolladores recuerden ejecutar npx prettier --write antes de cada commit no escala. Los Git hooks resuelven esto.

Configuración

npm install --save-dev husky lint-staged
npx husky init

Añade a package.json:

{
  "lint-staged": {
    "*.{js,jsx,ts,tsx}": [
      "prettier --write",
      "eslint --fix"
    ],
    "*.{json,md,css}": [
      "prettier --write"
    ]
  }
}

Actualiza el hook pre-commit de Husky (.husky/pre-commit):

npx lint-staged

Ahora cada commit formatea automáticamente los archivos en staging y ejecuta las correcciones de ESLint. Los desarrolladores nunca necesitan pensar en el formato: simplemente ocurre.

Este es el estándar de oro para proyectos en equipo: Prettier formatea, ESLint detecta errores, Husky aplica ambos en cada commit.

El debate de los punto y coma

Ninguna discusión sobre formato en JavaScript está completa sin la pregunta de los punto y coma. La respuesta práctica es la siguiente: no importa, siempre y cuando tu equipo sea consistente.

A favor de los punto y coma: La terminación explícita de sentencias evita los casos extremos de ASI (Automatic Semicolon Insertion). Las guías de estilo de Airbnb y Google los requieren.

Sin punto y coma: El ASI de JavaScript gestiona la terminación automáticamente. El código queda más limpio con menos ruido visual. La guía de estilo Standard los omite.

Los problemas de ASI sobre los que la gente advierte — como líneas que empiezan con ( o [ — son detectados por la regla no-unexpected-multiline de ESLint. En la práctica, prescindir de los punto y coma con un linting adecuado es perfectamente seguro.

Elige una opción, configura la opción semi de Prettier y sigue adelante. Prettier los añadirá o eliminará de forma consistente en cualquier caso.

Tabulaciones vs espacios en JavaScript

El ecosistema JavaScript usa abrumadoramente espacios, específicamente indentación de 2 espacios. Esto no es universal (Go usa tabulaciones, Python usa 4 espacios), pero en JavaScript es la convención predominante.

¿Por qué 2 espacios? Los patrones de callbacks anidados y métodos encadenados de JavaScript generan indentación profunda rápidamente. Dos espacios mantienen el código profundamente anidado legible sin empujarlo fuera del borde derecho de la pantalla.

¿Por qué no tabulaciones? Las tabulaciones permiten que cada desarrollador establezca su propio ancho de visualización, lo cual suena bien, pero significa que la alineación del código se rompe entre editores. Con espacios, lo que tú ves es lo que todos ven.

Configura esto una vez en Prettier (tabWidth: 2, useTabs: false) y EditorConfig (indent_style = space, indent_size = 2), y queda resuelto.

Errores comunes de formato

Funciones flecha inconsistentes

// Inconsistente — evita esto
const double = x => x * 2;
const add = (a, b) => a + b;
const greet = (name) => {
  return `Hello, ${name}`;
};

// Consistente — Prettier con arrowParens: "always"
const double = (x) => x * 2;
const add = (a, b) => a + b;
const greet = (name) => {
  return `Hello, ${name}`;
};

Estilo de desestructuración de objetos

// Apretado — difícil de leer
const {name,email,role} = user;

// Formateado — Prettier lo maneja automáticamente
const { name, email, role } = user;

// Multilínea para muchas propiedades
const {
  name,
  email,
  role,
  department,
  startDate,
} = user;

Organización de sentencias import

Prettier no ordena los imports — eso es una cuestión de calidad de código, no de formato. Usa eslint-plugin-import o el plugin simple-import-sort:

// Imports organizados
import React from 'react';
import { useState, useEffect } from 'react';

import { Button } from '@/components/Button';
import { Modal } from '@/components/Modal';

import { formatDate } from '../utils/dates';
import { validateEmail } from '../utils/validation';

Expresiones ternarias largas

// Ilegible en una sola línea
const label = isAdmin ? 'Admin Dashboard' : hasEditPermission ? 'Editor View' : 'Read Only';

// Prettier reformatea a multilínea legible
const label = isAdmin
  ? 'Admin Dashboard'
  : hasEditPermission
    ? 'Editor View'
    : 'Read Only';

Configuración de un proyecto nuevo

Aquí tienes una lista completa de pasos para configurar un proyecto nuevo de JavaScript o TypeScript:

1. Instala las dependencias:

   npm install --save-dev prettier eslint eslint-config-prettier husky lint-staged
   

2. Crea .prettierrc con las preferencias de tu equipo

3. Crea .editorconfig como base común entre editores

4. Configura ESLint solo con reglas de calidad de código (sin reglas de formato)

5. Configura Husky + lint-staged para aplicar las reglas en cada commit

6. Añade scripts a npm:

   {
     "scripts": {
       "format": "prettier --write .",
       "format:check": "prettier --check .",
       "lint": "eslint .",
       "lint:fix": "eslint --fix ."
     }
   }
   

7. Ejecuta el formateo inicial en todo el código base: npm run format

8. Haz commit del código formateado en un único commit para poder omitirlo fácilmente en git blame con --ignore-rev

El formateo en la práctica

Una vez que tu pipeline de formateo está configurado, la experiencia del día a día cambia drásticamente:

• Escribe código como quieras. Prettier reformatea al guardar o al hacer commit.
• Los pull requests muestran solo cambios de lógica. Se acabó el ruido de espacios en blanco.
• Los nuevos miembros del equipo son productivos de inmediato. Las herramientas aplican los estándares sin necesidad de un documento de guía de estilo.
• Las discusiones sobre estilo desaparecen. Prettier es la autoridad, no ningún desarrollador individual.

Cuando necesites verificar la estructura de datos JSON con los que estás trabajando, nuestro JSON Formatter facilita la inspección — pega cualquier JSON y obtén un formato legible al instante, directamente en tu navegador.

Recursos relacionados

Para más información sobre formateo de código y herramientas de desarrollo:

• Code Minification Guide — Aprende cuándo y cómo minificar JavaScript para producción
• Naming Conventions in Programming — Las convenciones de nomenclatura son la otra mitad del código legible
• SQL Formatting Best Practices — Aplica la misma disciplina de formateo a tus consultas de base de datos

El formato consistente es una de esas raras inversiones de ingeniería que da resultados de inmediato y sigue dando frutos. Configúralo una vez, automatízalo y dedica tu energía al código que realmente importa.