← Blog · 30 de abril de 2026 · Equipe ConvertCaseHQ · 7 min de leitura

camelCase vs. PascalCase: qual é a diferença?

A única diferença entre camelCase e PascalCase é a primeira letra. O camelCase começa com minúscula e põe maiúscula no início de cada palavra seguinte (userName, parseResponse). O PascalCase põe maiúscula em todas as palavras, inclusive na primeira (UserName, ResponseParser). Por convenção, o PascalCase indica tipos (classes, interfaces, enums, componentes React) e o camelCase indica valores e ações (variáveis, funções, métodos, propriedades).

Essa única maiúscula carrega mais informação do que parece. A seguir: o que ela sinaliza, as linguagens em que ela é obrigatória, e não só uma questão de boas maneiras, e a parte em que ninguém concorda, que são as siglas.

camelCase vs. PascalCase em resumo

Atenção ao vocabulário quando for ler guias de estilo. Muita gente diz “camel case” para os dois estilos, e a PEP 8 chega a listar CamelCase como outro nome de CapWords, o termo dela para PascalCase. Se o sentido de um guia não estiver claro, olhe os exemplos.

Por que a primeira letra importa: tipos vs. valores

A convenção permite ler código sem precisar consultar nada. Em const invoice = new Invoice(order), dá para ver de relance que Invoice é o que você constrói e invoice é o que você recebeu de volta. Assinaturas em TypeScript funcionam do mesmo jeito: em function total(order: Order): Money, o nome em minúscula é o valor e os nomes com maiúscula são tipos.

Ela também permite que a mesma palavra nomeie um tipo e um valor sem conflito, o que acontece o tempo todo: user: User, config: Config, request: Request. Numa linguagem que diferencia maiúsculas de minúsculas, esses são identificadores diferentes, e a maiúscula mostra a quem lê qual é qual.

Onde a linguagem obriga

Em JavaScript, Java, C# e Python, usar maiúscula ou minúscula no nome de uma classe é só convenção. Nada impede você de escrever class invoice. Em JavaScript, dá para transformar a convenção numa verificação com a regra new-cap do ESLint: por padrão, ela aponta new invoice() e também a chamada de uma função com maiúscula, como Invoice(), sem new, o que geralmente é um bug. Algumas linguagens e frameworks vão além e trazem a regra embutida.

Go: a primeira letra é a regra de visibilidade

Go não tem as palavras-chave public ou private. Um nome no nível do pacote, um campo de struct ou um método é exportado se a primeira letra for maiúscula, e privado ao pacote se for minúscula. É escolhendo entre PascalCase e camelCase que você decide.

package shapes

import "math"

// Circle is exported, so other packages can use it.
type Circle struct {
	Radius float64 // exported field
	label  string  // unexported field
}

// Area is exported.
func Area(c Circle) float64 { return math.Pi * square(c.Radius) }

// square is unexported: only code inside package shapes can call it.
func square(x float64) float64 { return x * x }

c := shapes.Circle{Radius: 2}
fmt.Println(shapes.Area(c))   // fine
fmt.Println(shapes.square(2)) // compile error: square is not exported

É também por isso que o Effective Go diz que um getter para um campo não exportado owner deve se chamar Owner, e não GetOwner. A maiúscula já mostra que esse é o acesso público.

React: componentes precisam começar com maiúscula

A documentação do React é taxativa: nomes de componentes precisam começar com letra maiúscula, senão não funcionam. O JSX trata uma tag em minúscula, como <section>, como elemento HTML, e uma com maiúscula, como <OrderSummary />, como um componente seu.

Ruby: nomes de classe são constantes

Em Ruby, qualquer nome que começa com letra maiúscula é uma constante, e nomes de classe precisam ser constantes. class Invoice funciona; class invoice é erro de sintaxe (“class/module name must be CONSTANT”).

Qual usar, linguagem por linguagem

• JavaScript e TypeScript: camelCase para variáveis, funções, métodos e propriedades; PascalCase para classes, interfaces, aliases de tipo, enums e componentes.
• Java e Kotlin: a mesma divisão, mais maiúsculas com sublinhados para constantes de verdade (MAX_RETRIES).
• C#: o PascalCase é muito mais comum do que em outras linguagens. Métodos, propriedades, eventos, campos públicos, namespaces e até constantes usam PascalCase; o camelCase fica para parâmetros e variáveis locais, com _camelCase para campos privados. Uma assinatura típica é public decimal CalculateTotal(decimal taxRate).
• Swift: PascalCase para tipos e protocolos, camelCase para todo o resto.
• Go: o que corresponder à visibilidade que você quer.
• Python: PascalCase só para classes. Funções e variáveis usam snake_case, e a PEP 8 só permite camelCase onde ele já é o estilo predominante em código antigo.
• PHP (PSR-1): classes em PascalCase, métodos em camelCase.

Para constantes, arquivos e o resto, veja nosso guia rápido de estilos de nomes para desenvolvedores.

A parte difícil: siglas e acrônimos

É userId ou userID? HttpClient ou HTTPClient? Os principais guias de estilo dão respostas diferentes:

Nossa opinião: se o guia da sua linguagem tem uma regra, siga-a, porque é o que a biblioteca padrão e seus colegas esperam. Se não tiver, trate siglas como palavras (HttpClient, userId). Os limites entre as palavras continuam visíveis quando duas siglas se encontram (compare XMLHTTPRequest com XmlHttpRequest), e os nomes sobrevivem à conversão automática entre estilos. Até o XMLHttpRequest do próprio navegador mistura as duas abordagens num só nome.

Para se aprofundar, as convenções de uso de maiúsculas da Microsoft são um bom exemplo de um conjunto completo de regras reunido numa única página.

Como converter entre camelCase e PascalCase

Num nome simples, a conversão muda um único caractere: basta trocar a primeira letra entre maiúscula e minúscula.

const toPascal = (s) => s.charAt(0).toUpperCase() + s.slice(1);
const toCamel = (s) => s.charAt(0).toLowerCase() + s.slice(1);

toPascal("orderTotal"); // "OrderTotal"
toCamel("OrderTotal");  // "orderTotal"
toCamel("HTMLParser");  // "hTMLParser" (acronyms need a smarter split)

Essa última linha é o motivo pelo qual as ferramentas primeiro dividem os nomes em palavras. Veja o que o conversor de maiúsculas e minúsculas do ConvertCaseHQ produz para algumas entradas complicadas:

Ele divide o nome nas maiúsculas que já existem e escreve siglas como palavras, o que bate com a regra do Google. Se o seu projeto segue as regras de siglas do Go, do .NET ou da PEP 8, corrija esses nomes à mão depois (getUserId vira getUserID em Go). Nomes de marcas são a outra armadilha: nenhum algoritmo sabe que IPhone parece errado.

Dois deslizes fáceis de evitar

O primeiro é pôr maiúscula numa instância: const Cart = new ShoppingCart() faz Cart parecer uma segunda classe, e a próxima pessoa que ler o código vai procurar a definição dela. O segundo é uma função auxiliar em PascalCase no JavaScript, como function FormatPrice(). A menos que seja um construtor ou um componente React, quem ler vai supor que ela precisa de new ou de JSX, e o new-cap vai reclamar quando você a chamar sem nenhum dos dois.

Uma regra prática

Se é um tipo, ou algo que você constrói com new, use PascalCase. Se é um valor ou uma ação, use camelCase. Deixe o guia da sua linguagem decidir as siglas e um linter se lembrar do resto. Para detalhes de JavaScript, incluindo constantes e campos privados, veja nosso guia de nomes em JavaScript.