← Blog · 16 de abril de 2026 · Equipe ConvertCaseHQ · 8 min de leitura

Nomes de variáveis em JavaScript: o guia de camelCase para desenvolvedores

Em JavaScript, use camelCase em variáveis, funções, parâmetros e propriedades de objetos (cartTotal, fetchOrders), PascalCase em classes e componentes React (ShoppingCart), e reserve o CONSTANT_CASE para valores que ficam fixos durante toda a vida do programa (MAX_RETRIES). Os guias de estilo de JavaScript do Google e do Airbnb concordam até aí, e os recursos nativos do próprio JavaScript seguem o mesmo padrão.

O restante deste guia mostra primeiro o que o motor JavaScript realmente impõe, depois as convenções criadas por cima disso e, por fim, os casos de borda em que as equipes divergem: quais valores const merecem maiúsculas, campos privados, siglas e dados em snake_case que chegam de uma API.

O que o próprio JavaScript permite

As regras da linguagem são curtas. Um identificador começa com uma letra, um sublinhado ou um cifrão, e os caracteres seguintes também podem ser dígitos. As letras não se limitam ao ASCII: o exemplo da própria MDN é a palavra alemã Früh. Os nomes diferenciam maiúsculas de minúsculas, então total e Total são duas variáveis diferentes, e palavras reservadas como new, class e delete não podem ser usadas como nomes de variáveis.

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

Os nomes de propriedades são ainda mais livres: qualquer string serve se você a puser entre aspas, e é assim que headers["Content-Type"] é possível. Tudo o que vai além dessas regras é convenção, e é justamente por isso que vale a pena combinar uma só para o time todo.

camelCase para variáveis, funções e propriedades

O camelCase é o padrão para quase tudo o que você nomeia em JavaScript. Dê nomes de substantivos aos valores e nomes de verbos às funções, para que a linha se leia como uma frase:

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

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

Para booleanos, um prefixo is, has ou can (isLoggedIn, hasAccess) responde à pergunta “verdadeiro ou falso em relação a quê?” antes que alguém precise fazê-la. O guia do Google usa os mesmos prefixos nos getters booleanos (isFoo, hasFoo).

O guia do Google também tem uma boa regra sobre tamanho: seja o mais descritivo que for razoável e não abrevie apagando letras. errorCount e customerId passam; nErr e cstmrId não. A exceção do guia é a variável com escopo de dez linhas ou menos, como o i de um laço curto ou o x em points.map((x) => x * 2).

Coleções, contagens e manipuladores de eventos

Alguns padrões deixam os nomes previsíveis. Use o plural para um array (users) e o singular para um item, de modo que for (const user of users) se leia com naturalidade. Dê a um objeto de consulta o nome da sua chave (usersById) e a um número o nome do que ele conta (userCount). No React, a documentação descreve uma convenção comum para eventos: os manipuladores levam handle mais o evento (handleClick), e as props que recebem um manipulador começam com on seguido de uma letra maiúscula (onClick, onSave).

PascalCase para classes, construtores e componentes

Tudo o que você constrói com new leva PascalCase, e o mesmo vale para tudo o que o React renderiza como componente:

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

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

Nas classes, é convenção. No React, é obrigatório: a documentação do React diz que os nomes de componentes precisam começar com letra maiúscula, senão não funcionam, porque o JSX trata tags em minúsculas, como <section>, como elementos HTML comuns. Em TypeScript, o mesmo PascalCase vale para interfaces, apelidos de tipo (type aliases) e enums.

Os recursos nativos servem de modelo para tudo isso. Os construtores são em PascalCase (Map, Promise, Date), os métodos são em camelCase (Object.fromEntries, Array.prototype.flatMap) e os valores fixos são em maiúsculas (Math.PI, Number.MAX_SAFE_INTEGER).

Quando usar CONSTANT_CASE (e quando não usar)

As constantes causam a maior confusão, porque const não significa “constante”. Ele só impede que a variável seja reatribuída; o array ou o objeto para o qual ela aponta ainda pode mudar. Os dois grandes guias de estilo reservam as maiúsculas para algo mais rígido:

Google: CONSTANT_CASE é para valores de nível de módulo (e propriedades estáticas) profundamente imutáveis. Só ter a intenção de nunca mudar um objeto não basta, e constantes declaradas dentro de funções continuam em lowerCamelCase.
Airbnb: as maiúsculas são opcionais e só valem para um valor exportado, declarado com const e que dá para ter certeza de que nunca vai mudar (propriedades aninhadas incluídas). Pôr em maiúsculas todo const dentro de um arquivo é desnecessário.

// 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;
}

Os guias divergem quanto às chaves de um objeto no estilo enum. O Google escreve os membros do enum em CONSTANT_CASE, como acima; o Airbnb prefere chaves em minúsculas dentro de um export em maiúsculas. Qualquer um dos dois serve, desde que a base de código inteira faça igual. Mais uma pegadinha: Object.freeze é raso (shallow), então um objeto congelado ainda pode conter um objeto aninhado que muda.

Campos privados: use #, não sublinhado

O velho hábito de marcar membros “privados” com um sublinhado no início (this._count) é só uma dica: qualquer pessoa ainda pode ler e gravar a propriedade. O guia do Airbnb manda não usar sublinhados no início nem no fim justamente por isso, e o guia de TypeScript do Google também os proíbe como prefixo e sufixo. O JavaScript moderno tem campos privados de verdade:

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 ou userID?

A regra do Google é tratar as siglas como palavras comuns: customerId, xmlHttpRequest, loadHttpUrl. A do Airbnb é o oposto: manter a sigla toda em maiúsculas ou toda em minúsculas, como em SMSContainer ou httpRequests. O próprio navegador não consegue se decidir, com XMLHttpRequest, innerHTML, getElementById e encodeURIComponent convivendo na mesma plataforma.

Nós ficaríamos com a regra do Google, porque ela é previsível, mantém os limites entre as palavras visíveis e converte sem problemas entre estilos. Mas a consistência importa mais do que a escolha. Comparamos a regra de siglas de cada guia importante em camelCase vs. PascalCase.

Como lidar com dados em snake_case vindos de APIs

APIs baseadas em Python, Ruby ou num banco SQL muitas vezes entregam chaves como first_name. Não deixe que elas se espalhem pelo seu código. Renomeie no ponto em que os dados chegam; a desestruturação transforma isso numa linha só:

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

Para payloads inteiros, escreva uma função pequena para cada direção que converta as chaves de forma recursiva e chame-a no seu cliente de API; mostramos um passo a passo em como converter JSON de camelCase para snake_case. Para renomear um nome só, nosso conversor de maiúsculas e minúsculas transforma last_login em lastLogin com um clique.

Faça o ESLint impor as regras

Duas regras do núcleo do ESLint cobrem a maior parte disso. A camelcase sinaliza sublinhados no meio dos nomes, ignorando constantes todas em maiúsculas e sublinhados no início ou no fim. A new-cap sinaliza new usado com um nome em minúsculas e uma função com inicial maiúscula chamada sem new.

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

A opção properties: "never" evita que a camelcase reclame de campos de API como data.first_name, sem deixar de checar as variáveis que você declara. Em projetos TypeScript, a @typescript-eslint/naming-convention vai além e deixa você definir um formato permitido para cada tipo de identificador: variáveis, funções, classes, parâmetros de tipo e mais. O conjunto completo das regras do Google está no Google JavaScript Style Guide.

Um checklist de nomes de variáveis em JavaScript

camelCase para variáveis, funções, parâmetros, métodos e propriedades.
PascalCase para classes, construtores, componentes React e tipos, interfaces e enums do TypeScript.
CONSTANT_CASE para valores de nível de módulo que nunca mudam, e não para todo const.
Campos #private em vez de prefixos com sublinhado.
Uma única regra para siglas, escrita no guia de contribuição.
Chaves snake_case de APIs convertidas uma só vez, na fronteira.