← Blog · 16 de abril de 2026 · Equipo de ConvertCaseHQ · 8 min de lectura

Cómo nombrar variables en JavaScript: guía de camelCase y convenciones

En JavaScript, escribe en camelCase los nombres de variables, funciones, parámetros y propiedades de objetos (cartTotal, fetchOrders), en PascalCase los de clases y componentes de React (ShoppingCart), y reserva CONSTANT_CASE para los valores que no cambian durante toda la vida del programa (MAX_RETRIES). Las guías de estilo de JavaScript de Google y de Airbnb coinciden en eso, y los elementos integrados del propio JavaScript siguen el mismo patrón.

El resto de esta guía explica lo que el motor impone de verdad, luego las convenciones que se aplican por encima y, por último, los casos límite en los que los equipos discrepan: qué valores const merecen mayúsculas, los campos privados, las siglas y los datos en snake_case que llegan de una API.

Lo que permite el propio JavaScript

Las reglas del lenguaje son pocas. Un identificador empieza por una letra, un guion bajo o un signo de dólar, y los caracteres siguientes también pueden ser dígitos. Las letras no se limitan a ASCII: el propio ejemplo de MDN es la palabra alemana Früh. Los nombres distinguen entre mayúsculas y minúsculas, así que total y Total son dos variables distintas, y las palabras reservadas como new, class y delete no pueden usarse como nombres de variable.

let total = 1;
let Total = 2;      // a different variable
const café = "ok";  // Unicode letters are allowed
const $price = 9.99;
const _unused = null;

// const 2fast = true;  // SyntaxError: can't start with a digit
// const new = 1;       // SyntaxError: reserved word

Los nombres de propiedades son todavía más permisivos: vale cualquier cadena si la pones entre comillas, y por eso es posible escribir headers["Content-Type"]. Todo lo que va más allá de estas reglas es convención, y justo por eso conviene ponerse de acuerdo.

camelCase para variables, funciones y propiedades

camelCase es la opción por defecto para casi todo lo que nombras en JavaScript. Da a los valores nombres de sustantivo y a las funciones nombres de verbo, para que una línea se lea como una frase:

const orderCount = orders.length;
const isLoggedIn = Boolean(session);
const user = { firstName: "Ada", lastLogin: null };

function calculateShipping(order) {
  // ...
}

En los booleanos, un prefijo is, has o can (isLoggedIn, hasAccess) responde a la pregunta «¿verdadero o falso de qué?» antes de que nadie tenga que hacerla. La guía de Google usa los mismos prefijos para los getters booleanos (isFoo, hasFoo).

La guía de Google también tiene una buena regla sobre la longitud: sé tan descriptivo como razonablemente puedas y no abrevies quitando letras. errorCount y customerId pasan la prueba; nErr y cstmrId no. La excepción de la guía es una variable cuyo ámbito dura diez líneas o menos, como la i de un bucle corto o la x de points.map((x) => x * 2).

Colecciones, contadores y manejadores de eventos

Unos pocos patrones hacen que los nombres sean predecibles. Usa el plural para un array (users) y el singular para un elemento, de modo que for (const user of users) se lea con naturalidad. Nombra un objeto de búsqueda según su clave (usersById) y un número según lo que cuenta (userCount). En React, la documentación describe una convención habitual para los eventos: los manejadores se llaman handle más el evento (handleClick), y las props que reciben un manejador empiezan por on y una letra mayúscula (onClick, onSave).

PascalCase para clases, constructores y componentes

Todo lo que construyes con new va en PascalCase, y también todo lo que React renderiza como componente:

class ShoppingCart {
  addItem(item) {
    // ...
  }
}
const cart = new ShoppingCart();

function OrderSummary({ order }) {
  return <section>{order.id}</section>;
}

En las clases es una convención. En React es obligatorio: la documentación de React dice que los nombres de los componentes deben empezar por una letra mayúscula o no funcionarán, porque JSX trata las etiquetas en minúscula como <section> como elementos HTML normales. En TypeScript, el mismo PascalCase se aplica a las interfaces, los alias de tipo y los enums.

Los elementos integrados ilustran todo esto. Los constructores van en PascalCase (Map, Promise, Date), los métodos en camelCase (Object.fromEntries, Array.prototype.flatMap) y los valores fijos en mayúsculas (Math.PI, Number.MAX_SAFE_INTEGER).

Cuándo usar CONSTANT_CASE (y cuándo no)

Las constantes son lo que más confunde, porque const no significa «constante». Solo impide reasignar la variable; el array o el objeto al que apunta todavía puede cambiar. Las dos grandes guías de estilo reservan las mayúsculas para algo más estricto:

Google: CONSTANT_CASE es para valores de nivel de módulo (y propiedades estáticas) profundamente inmutables. No basta con tener la intención de no cambiar nunca un objeto, y las constantes declaradas dentro de funciones siguen en lowerCamelCase.
Airbnb: las mayúsculas son opcionales, y solo para un valor que se exporta, se declara con const y es seguro que nunca cambiará (incluidas sus propiedades anidadas). No hace falta poner en mayúsculas cada const de un archivo.

// Module level, never changes: capitals
export const MAX_UPLOAD_BYTES = 5 * 1024 * 1024;
export const ORDER_STATUS = Object.freeze({ PENDING: "pending", SHIPPED: "shipped" });

function visibleNames(items) {
  const visible = items.filter((item) => !item.hidden); // const, but not a constant
  const names = [];                                     // const binding, mutable array
  for (const item of visible) names.push(item.name);
  return names;
}

Las guías discrepan en las claves de un objeto tipo enum. Google escribe los miembros del enum en CONSTANT_CASE, como arriba; Airbnb prefiere claves en minúscula dentro de una exportación en mayúsculas. Cualquiera de las dos vale si todo el código hace lo mismo. Un matiz más: Object.freeze es superficial, así que un objeto congelado todavía puede contener un objeto anidado que cambie.

Campos privados: usa #, no un guion bajo

La vieja costumbre de marcar los miembros «privados» con un guion bajo inicial (this._count) es solo una pista; cualquiera puede seguir leyendo y escribiendo la propiedad. La guía de Airbnb dice que no se usen guiones bajos iniciales ni finales por esa misma razón, y la guía de TypeScript de Google también los prohíbe como prefijos y sufijos. El JavaScript moderno tiene campos privados de verdad:

class Counter {
  #count = 0;
  increment() {
    return ++this.#count;
  }
}

const counter = new Counter();
counter.increment();
counter.count;   // undefined
// counter.#count  // SyntaxError outside the class

Siglas: ¿userId o userID?

La regla de Google es tratar las siglas como palabras normales: customerId, xmlHttpRequest, loadHttpUrl. La de Airbnb es la contraria: mantener una sigla toda en mayúsculas o toda en minúsculas, como en SMSContainer o httpRequests. El propio navegador no se decide, con XMLHttpRequest, innerHTML, getElementById y encodeURIComponent conviviendo en la misma plataforma.

Nosotros elegiríamos la regla de Google, porque es predecible, mantiene visibles los límites entre palabras y se convierte sin problemas entre estilos. Pero la coherencia importa más que la elección. Comparamos la regla de siglas de todas las guías principales en camelCase frente a PascalCase.

Cómo tratar los datos en snake_case que llegan de las APIs

Las APIs respaldadas por Python, Ruby o una base de datos SQL suelen entregarte claves como first_name. No dejes que se extiendan por tu código. Renómbralas en el punto donde llegan los datos, y la desestructuración lo deja en una sola línea:

const response = await fetch("/api/users/42");
const { first_name: firstName, last_login: lastLogin } = await response.json();

Para payloads completos, escribe una pequeña función para cada dirección que convierta las claves de forma recursiva y llámala desde tu cliente de la API; en convertir JSON de camelCase a snake_case recorremos una paso a paso. Para un cambio de nombre puntual, nuestro conversor de mayúsculas y minúsculas convierte last_login en lastLogin con un solo clic.

Hazlo cumplir con ESLint

Dos reglas básicas de ESLint cubren casi todo esto. camelcase marca los guiones bajos en medio de los nombres e ignora las constantes en mayúsculas y los guiones bajos iniciales o finales. new-cap marca el uso de new con un nombre en minúscula, y una función con mayúscula inicial llamada sin new.

// eslint.config.js
export default [
  {
    rules: {
      camelcase: ["error", { properties: "never" }],
      "new-cap": "error",
    },
  },
];

La opción properties: "never" evita que camelcase se queje de campos de API como data.first_name y sigue comprobando las variables que declaras. En los proyectos de TypeScript, @typescript-eslint/naming-convention va más lejos y te deja fijar un formato permitido para cada tipo de identificador: variables, funciones, clases, parámetros de tipo y más. El conjunto completo de reglas de Google está en la Google JavaScript Style Guide.

Una lista de comprobación para nombrar variables en JavaScript

camelCase para variables, funciones, parámetros, métodos y propiedades.
PascalCase para clases, constructores, componentes de React y tipos, interfaces y enums de TypeScript.
CONSTANT_CASE para los valores de nivel de módulo que nunca cambian, no para cada const.
Campos #private en lugar de prefijos con guion bajo.
Una sola regla para las siglas, escrita en tu guía de contribución.
Claves de API en snake_case convertidas una sola vez, en el punto de entrada.