Quando o código vira uma festa de nomes: camelCase, PascalCase, snake_case e outros bichos

Eu confesso: quando comecei a programar, achava que nome de variável era igual apelido de colega de escola. Qualquer coisa servia, desde que eu entendesse. Então nasciam monstros como x1, coisa, valorFinalMesmoAgora, teste2_final_agoraVai e o lendário aux.

O problema é que o código tem uma característica cruel: ele sempre volta. Você escreve hoje, esquece amanhã e daqui a três meses olha para aquilo como se tivesse sido feito por uma inteligência alienígena com pressa.

Por isso, nomear bem classes, funções, variáveis e constantes não é frescura. É engenharia. É comunicação. É documentação embutida no próprio código. E, quando bem feita, evita aquela clássica pergunta existencial:

“Quem foi o animal que escreveu isso?”

A resposta, quase sempre, é: eu mesmo.

Nomear código é dar placas para uma cidade

Imagine uma cidade onde as ruas se chamam Rua A, Rua B, Rua Coisa, Rua Nova 2, Rua Final_Final_AgoraVai. Ninguém chega a lugar nenhum. O entregador se perde, o GPS chora, e o carteiro pede demissão.

O código é a mesma coisa. Classes, funções, variáveis e constantes são como ruas, prédios, departamentos e placas de orientação. Quando usamos bons nomes e seguimos um padrão, o código começa a conversar conosco.

Por exemplo:

int temperaturaMotor;

Aqui eu já sei que existe uma temperatura associada ao motor.

Agora veja:

int x;

Esse x pode ser temperatura, velocidade, idade do cachorro, número de tentativas ou a quantidade de café restante na garrafa. Ninguém sabe. Talvez nem quem escreveu.

camelCase: o camelo elegante do JavaScript

O camelCase recebe esse nome porque a palavra começa minúscula e depois vai criando “corcovas” com letras maiúsculas no meio. É como um camelo atravessando o deserto do código.

Exemplo:

let nomeDoUsuario = "Carlos";
let temperaturaDoMotor = 85;

A primeira palavra começa com letra minúscula. As próximas começam com letra maiúscula. Esse formato é muito usado para variáveis e funções em JavaScript, Java, TypeScript e várias outras linguagens.

Eu gosto do camelCase quando estou escrevendo código mais próximo de aplicação, interface, backend ou scripts. Ele é limpo, compacto e fácil de ler quando os nomes não ficam gigantes.

O problema começa quando alguém resolve escrever:

let valorFinalCalculadoDepoisDaRevisaoDoClienteComDescontoAplicado = 100;

Aí não é mais camelCase. É uma cobra tentando se passar por camelo.

PascalCase: o terno social das classes

O PascalCase é parecido com o camelCase, mas começa com letra maiúscula. É muito usado para nomear classes, tipos, interfaces, componentes e estruturas importantes.

Exemplo:

public class ClientePremium
{
}

Ou em TypeScript:

class SensorDeTemperatura {
}

Aqui cada palavra começa com letra maiúscula. O nome ganha uma aparência mais “nobre”, como se dissesse: “com licença, eu sou uma classe, me respeite”.

Em muitas linguagens, quando eu vejo PascalCase, já penso em algo que representa uma entidade, um modelo, uma classe ou um tipo de dado.

Por exemplo:

class PedidoDeCompra {}
interface UsuarioAutenticado {}
type ResultadoDaOperacao = {}

Perceba que o nome já diz que aquilo não é uma variável qualquer. É uma construção mais estrutural.

snake_case: a cobra organizada do Python e do C

O snake_case separa as palavras com sublinhado _. Ele é muito comum em Python, C, bancos de dados e também aparece bastante em sistemas embarcados.

Exemplo:

nome_do_usuario = "Carlos"
temperatura_do_motor = 85

Em C:

int temperatura_do_motor;
void inicializar_sensor_adc(void);

Eu particularmente tenho carinho pelo snake_case, especialmente em C, porque ele combina bem com o estilo mais direto da linguagem. Em sistemas embarcados, onde nomes precisam ser claros e às vezes descrever periféricos, registradores, estados e módulos, ele ajuda bastante.

Por exemplo:

uint16_t adc_valor_bruto;
float corrente_motor_ampere;
bool sensor_temperatura_ativo;

Fica claro, legível e sem parecer que o nome está pulando lombadas.

UPPER_SNAKE_CASE: quando a constante grita educadamente

O UPPER_SNAKE_CASE é geralmente usado para constantes, macros e valores fixos. Ele parece uma placa de advertência dizendo:

“Ei, isso aqui é importante e provavelmente não deve mudar!”

Exemplo em C:

#define LIMITE_MAXIMO_CORRENTE 10
#define TAXA_AMOSTRAGEM_ADC 1000

Em JavaScript:

const TEMPO_MAXIMO_ESPERA = 5000;

Esse estilo é muito comum para constantes globais ou valores de configuração. O uso de letras maiúsculas ajuda a diferenciar rapidamente uma constante de uma variável comum.

Agora, claro, se tudo no código estiver em maiúsculo, parece que o programa está gritando com você o tempo todo:

INT VALOR = CALCULAR_COISA(ENTRADA);

Calma, programa. Vamos conversar.

kebab-case: o churrasquinho do HTML e das URLs

O kebab-case separa palavras com hífen -. Ele é muito comum em URLs, nomes de arquivos web, classes CSS e atributos HTML customizados.

Exemplo:

<div class="card-produto-destaque"></div>

Em URLs:

/artigo-sobre-sistemas-embarcados

O nome vem da ideia de palavras espetadas por hífens, como pedaços de carne num kebab. É um nome engraçado, mas bem apropriado.

Porém, em muitas linguagens de programação, o hífen não pode ser usado em nomes de variáveis, porque ele é interpretado como sinal de subtração.

Por exemplo, isso não funciona como variável em JavaScript:

let nome-do-usuario = "Carlos";

O interpretador entende algo parecido com:

nome - do - usuario

Ou seja, ele acha que você quer fazer uma conta, não criar um nome. E aí começa o festival de erro.

flatcase: tudo grudado, seja o que Deus quiser

O flatcase escreve tudo em minúsculas, sem separadores.

Exemplo:

nomedousuario
temperaturadomotor

Ele pode aparecer em alguns contextos simples, nomes curtos, comandos, pacotes ou identificadores, mas não é ideal para nomes longos. O cérebro humano sofre um pouco tentando separar as palavras.

Veja:

calculovalorfinalpedido

Isso é calculo valor final pedido, calculo valor final do pedido, calcula o valor final pedido, ou uma senha de Wi-Fi?

Para nomes curtos, até vai:

login
status
config

Mas para nomes compostos, eu evitaria.

SCREAMINGCASE: quando removeram até o sublinhado

O SCREAMINGCASE é tudo maiúsculo, sem separadores:

VALORMAXIMO
TEMPERATURAALTA

Não é tão legível quanto UPPER_SNAKE_CASE, porque as palavras ficam grudadas. Ele pode aparecer em sistemas antigos, identificadores limitados ou convenções específicas, mas não é o formato mais amigável para leitura.

Compare:

#define TEMPERATURAMAXIMAMOTOR 90

Com:

#define TEMPERATURA_MAXIMA_MOTOR 90

O segundo respira melhor. O primeiro parece uma placa escrita às pressas por alguém fugindo de um bug.

Hungarian notation: o crachá pendurado no nome

A notação húngara foi muito usada em alguns ambientes, especialmente em programação Windows mais antiga. A ideia é colocar um prefixo indicando o tipo ou a finalidade da variável.

Exemplo:

int iContador;
char *pszNome;
bool bAtivo;

Aqui, i indica inteiro, psz indica ponteiro para string terminada em zero, b indica booleano.

Ela pode ser útil em alguns contextos de baixo nível, mas hoje é bastante questionada. Em linguagens modernas, o editor, o compilador e o sistema de tipos já ajudam muito. Então, escrever o tipo dentro do nome pode virar repetição desnecessária.

Por exemplo:

let strNome: string;
let numIdade: number;

Em TypeScript, isso é meio como colocar uma etiqueta dizendo “água” em uma garrafa transparente cheia de água. Não está errado em todos os cenários, mas pode ser redundante.

Tabela dos principais formatos de nomeação

FormatoExemploUso comumLinguagens onde aparece bastantecamelCasenomeDoUsuarioVariáveis, funções, métodosJavaScript, TypeScript, Java, Kotlin, SwiftPascalCaseNomeDoUsuarioClasses, tipos, interfaces, componentesC#, Java, TypeScript, Pascal, Delphi, Swiftsnake_casenome_do_usuarioVariáveis, funções, nomes de módulosPython, C, Rust, Ruby, bancos SQLUPPER_SNAKE_CASENOME_DO_USUARIOConstantes, macros, configurações fixasC, C++, Python, Java, JavaScriptkebab-casenome-do-usuarioURLs, classes CSS, nomes de arquivos webHTML, CSS, JavaScript em contexto webflatcasenomedousuarioIdentificadores simples e curtosGo em pacotes, comandos, nomes simplesSCREAMINGCASENOMEDOUSUARIOConstantes antigas ou contextos restritosSistemas legados, macros antigasHungarian notationstrNome, iContadorPrefixo indicando tipo ou funçãoC, C++, WinAPI, códigos legadosdot.caseusuario.nomeCaminhos, chaves de configuração, objetosJSON, YAML, configurações, logsTrain-CaseNome-Do-UsuarioCabeçalhos HTTP antigos ou nomes formaisHTTP headers, documentos técnicosTitle CaseNome Do UsuarioTexto exibido para humanosInterfaces, títulos, relatórios

Classes, funções, variáveis e constantes: cada um no seu quadrado

Na prática, a nomeação costuma seguir uma lógica semântica. Ou seja, não é apenas estética. O formato ajuda a dizer o que aquele elemento representa.

Para classes, normalmente usamos nomes que representam coisas, entidades ou conceitos. Por isso, é comum usar substantivos em PascalCase.

class SensorTemperatura {}
class ControladorMotor {}
class PedidoCompra {}

Para funções, o ideal é usar verbos ou expressões de ação, porque função faz alguma coisa.

calcularTotal()
enviarMensagem()
inicializarSensor()

Para variáveis, usamos nomes que representam valores, estados ou referências.

temperaturaAtual
usuarioLogado
quantidadeDeTentativas

Para constantes, usamos nomes que indicam valores fixos ou limites.

#define LIMITE_MAXIMO_TENTATIVAS 3
#define TEMPERATURA_CRITICA_MOTOR 90

A regra mental que eu gosto é simples: classe é coisa, função é ação, variável é estado ou valor, constante é regra fixa.

O terror dos nomes genéricos

Todo programador, em algum momento da vida, já criou uma variável chamada data.

let data = getData();

Parece inofensivo. Mas data pode ser qualquer coisa: data de calendário, dados de usuário, resposta da API, conteúdo do formulário, pacote binário, leitura do sensor, lista de clientes ou um buraco negro em formato JSON.

Melhor seria:

let dadosDoUsuario = getUserData();
let respostaDaApi = await buscarPedidos();
let leituraDoSensor = obterLeituraAdc();

Nomes genéricos economizam segundos na escrita e roubam horas na manutenção.

Outros suspeitos conhecidos:

temp
aux
obj
valor
coisa
teste
novo
final
final2
agoraVai

Eu não julgo. Já usei todos. Mas hoje eu trato esses nomes como trato fio desencapado: com respeito, distância e um pouco de medo.

O nome não precisa ser curto; precisa ser claro

Existe uma diferença entre nome curto e nome bom.

int v;

É curto, mas não diz nada.

int velocidade_motor_rpm;

É maior, mas explica exatamente o que representa.

Em sistemas embarcados, isso é ainda mais importante, porque muitas vezes estamos lidando com unidades físicas. Sempre que possível, gosto de colocar a unidade no nome:

float tensao_bateria_volts;
float corrente_motor_ampere;
uint32_t tempo_espera_ms;
uint16_t frequencia_pwm_hz;

Isso evita erros graves. Um clássico é misturar segundos, milissegundos e microssegundos. Quando o nome indica a unidade, o risco diminui muito.

Compare:

delay(tempo);

Com:

delay_ms(tempo_espera_ms);

O segundo deixa menos espaço para tragédia.

Padrão ruim ainda é melhor que bagunça total

Uma coisa importante: não existe um único padrão universal perfeito. Cada linguagem tem sua cultura. Cada equipe tem suas convenções. Cada projeto pode ter seu estilo.

O problema não é escolher camelCase ou snake_case. O problema é usar tudo ao mesmo tempo sem critério:

let nome_usuario;
let NomeUsuario;
let nomeUsuario;
let NOMEusuario;
let nomeusuario_final;

Isso parece menos um código e mais uma reunião de família onde ninguém se fala.

A consistência é o ponto central. Se o projeto usa camelCase para variáveis, siga isso. Se usa snake_case em C, siga isso. Se constantes são UPPER_SNAKE_CASE, mantenha assim.

Código bem padronizado não é apenas bonito. Ele reduz esforço mental. Você entende mais rápido. Erra menos. E sofre menos quando precisa dar manutenção.

Um exemplo ruim e um exemplo melhor

Agora vejamos um pequeno desastre:

let x = 10;
let y = 20;
let z = x * y;

function faz(a, b) {
return a * b;
}

Funciona? Sim.

Explica alguma coisa? Quase nada.

Agora uma versão melhor:

let larguraRetangulo = 10;
let alturaRetangulo = 20;
let areaRetangulo = calcularAreaRetangulo(larguraRetangulo, alturaRetangulo);

function calcularAreaRetangulo(largura, altura) {
return largura * altura;
}

Agora o código fala. Ele não apenas executa. Ele ensina o leitor.

E esse é o ponto: código bom não é aquele que só o computador entende. É aquele que outro ser humano consegue entender sem precisar acender vela, abrir o depurador e fazer arqueologia.

Conclusão

Nomear bem é uma das habilidades mais subestimadas da programação. Muita gente quer aprender framework, arquitetura, banco de dados, inteligência artificial, microcontrolador, nuvem, DevOps e até computação quântica, mas continua criando variável chamada aux.

O nome é a primeira documentação do código. Antes de um comentário, antes de um README, antes de um diagrama, existe um identificador dizendo: “eu sou isto e faço aquilo”.

Então, quando eu escolho entre camelCase, PascalCase, snake_case, kebab-case ou qualquer outro formato, não estou apenas escolhendo estética. Estou escolhendo como meu código será lido, mantido e entendido.

E no fim das contas, programar é isso: escrever instruções para a máquina, mas deixar pistas suficientes para que os humanos não enlouqueçam no caminho.