Camelo é paroxítona: por que essa analogia funciona (e onde ela falha)
A analogia entre camelCase e palavras paroxítonas do português aparece com frequência em salas de aula de programação, e geralmente funciona como um gancho inicial. A ideia é simples: assim como uma paroxítona tem a tonicidade na penúltima sílaba, uma variável em camelCase tem seu destaque (a letra maiúscula) nas sílabas não iniciais. O primeiro elemento fica em minúsculas, os seguintes "ganham acento tônico" visual. É prático até certo ponto. Eu já vi esse argumento sendo usado para ensinar convenções de nomenclatura para iniciantes, e ele resolve o problema básico de introduzir o conceito sem precisar falar de convenções da Apple, do Java ou de padrões que ninguém se importa no começo. Mas a analogia tem limites sérios que raramente são mencionados.
Camelo é paroxítona — a analogia em prática
Pra entender até onde ela chega, comparemos os dois sistemas. Palavras paroxítonas em português: "cafeteria", "programação", "variável". A sílaba tônica é sempre a penúltima. Regra geral, sem muitas exceções razoáveis. Já o camelCase: "meuNomeDeVariavel", "calculadoraIMC", "listaDeProdutos". O "destaque" pode aparecer em qualquer posição após o primeiro elemento. Não há uma regra fixa de frequência. A analogia só funciona no sentido estrutural básico: ambos têm um elemento inicial sem destaque e elementos subsequentes marcados. O problema é que paroxítona é uma classificação fonológica com regras bem definidas. CamelCase é uma convenção de nomenclatura arbitrária que nasceu em contextos específicos e depois se espalhou. Dizer que "camelo é paroxítona" dá a impressão de que existe uma regra natural por trás, quando na verdade é apenas um acordo entre desenvolvedores.
Na prática, isso significa que alunos costumam aplicar a lógica de forma inconsistente. Eu já corrigi código onde pessoas escreviam "listaDeProdutosDisponiveis" como se fosse uma palavra só, sem respeitar os limites dos morfemas, ou criavam variações como "oMeuPrimeiroProjeto_2023" misturando underline porque "sentia que estava errado" não usar. A analogia fonológica não ensina nada sobre divisão de componentes semânticos.
👉 Clique no botão abaixo para saber mais sobre o assunto!
O que a analogia não mostra
CamelCase tem regras de formação que nada têm a ver com tonicidade. A primeira palavra sempre em minúsculas. Cada nova palavra significativa começa com maiúscula. Sem espaços, sem underscores (a menos que você esteja usando outro estilo). E existem variações: PascalCase começa com maiúscula, snake_case usa underscores, kebab-case usa traços. A paroxítona não tem essas variantes. Também não aborda o aspecto mais importante na vida real: legibilidade em diferentes contextos. Uma variável como "URLParser" fica estranha porque a sigla quebra a expectativa de que cada maiúscula marca uma nova palavra. Já "urlParser" ou "URLParser" são escolhas que geram discussão acalorada em code reviews. Nenhuma regra fonológica explica isso.
Outro ponto que a analogia esconde: camelCase não é universal. Bibliotecas e frameworks diferentes adotam convenções distintas. Go prefere snake_case para nomes exported. Python segue PEP 8 e recomenda snake_case para funções e variáveis. JavaScript no browser com DOM frequentemente usa hyphen-case em atributos HTML. Dizer que "camelo é paroxítona" não prepara ninguém para essas exceções.
Quando a analogia funciona e quando você deve abandoná-la
Funciona bem no primeiro contato: mostrar que camelCase não é aleatório, que existe um padrão visual perceptível. Funciona para programadores lusófonos porque o conceito de paroxítona já existe no repertório linguístico deles. Leva talvez dez minutos pra desgrudar o conceito da cabeça de alguém que nunca viu uma variável nomeada em vida. Deve ser abandonada quando for preciso discutir nomes compostos por siglas, nomes que incluem números, contextos multiplataforma, ou qualquer situação onde a convenção do projeto diverge do camelCase estrito. Nesse ponto, continuar usando a analogia gera mais confusão do que clareza. Eu já vi desenvolvedores júnior hesitarem entre usar "HTTPResponse" ou "httpResponse" porque a analogia fonológica não lhes dava ferramenta pra decidir. A resposta correta depende das guidelines do projeto, não da fonética portuguesa.
A analogia é útil como ponte pedagógica. Não é fundamento. E confundir os dois é o tipo de erro que aparece months depois, quando alguém precisa justificar uma convenção de nomenclatura em documentação técnica ou num debate de architecture decision record.
