Conversor de Maiúsculas

Os formatos e onde cada um se encaixa

camelCase começa em minúscula e põe maiúscula no início de cada palavra seguinte; é a convenção para variáveis e funções em JavaScript, Java e Swift. PascalCase põe maiúscula também na primeira palavra e costuma ser reservado para tipos, classes e componentes. snake_case une palavras minúsculas com sublinhados e é padrão em Python, Ruby, Rust e identificadores SQL. SCREAMING_SNAKE_CASE é o mesmo em maiúsculas, usado quase só para constantes e variáveis de ambiente.

kebab-case une palavras minúsculas com hifens e pertence a lugares onde sublinhados são incômodos ou invisíveis: slugs de URL, nomes de classes e propriedades personalizadas em CSS, atributos HTML, flags de linha de comando, nomes de pacotes npm. dot.case aparece em chaves de configuração e configurações com namespace.

Escolher o certo raramente é questão de gosto. Cada ecossistema tem uma convenção, os linters a impõem, e um identificador no formato errado parece estrangeiro no arquivo em que cai.

Separar as palavras é a parte difícil

Converter entre formatos é fácil quando você sabe onde estão as palavras, e encontrar as palavras é onde implementações ingênuas tropeçam. A entrada é dividida em sublinhados, hifens, pontos e espaços, e também nas fronteiras entre maiúsculas e minúsculas, então userName e user_name resultam nas mesmas duas palavras.

Sequências de maiúsculas são tratadas como uma palavra só, e não uma palavra por letra. XMLHttpRequest vira XML, Http, Request, gerando xml_http_request em vez de x_m_l_http_request, e getUserID mantém o ID inteiro. A regra é que uma sequência de maiúsculas termina um caractere antes de uma minúscula que vem depois, e é isso que faz o H de Http começar uma nova palavra em vez de terminar a anterior.

Dígitos ficam grudados à palavra que os precede, então parseInt32 vira parse, Int32. Separadores no início e no fim são descartados, e separadores repetidos se fundem.

Formatos para texto, e CJK

Title Case não é simplesmente pôr maiúscula em toda palavra. Guias de estilo em inglês mantêm artigos, preposições curtas e conjunções coordenativas em minúsculas, a não ser que abram ou fechem o título, e por isso o resultado é The Lord of the Rings e não The Lord Of The Rings. Os guias discordam sobre onde fica o limite, principalmente em preposições de quatro letras ou mais, então confira o seu se isso importar. Sentence case põe maiúscula só na primeira palavra e deixa o resto, e vem se tornando o padrão para títulos em muitos sites.

Japonês, chinês e coreano não têm distinção entre maiúsculas e minúsculas, então esses caracteres passam intactos. Em texto misto, só os trechos em alfabeto latino são convertidos. Um trecho CJK é tratado como uma única palavra, porque separá-lo em palavras exige um dicionário e um segmentador, e chutar as fronteiras produziria uma saída errada com toda a confiança.

A ida e volta perde informação

Converter um identificador para outro formato e voltar nem sempre devolve o original. snake_case para camelCase e de volta é seguro, porque as fronteiras dos sublinhados sobrevivem como fronteiras de maiúsculas. Tudo o que envolve sigla não é: HTTPServer vira http_server, e converter de volta dá HttpServer. A informação de que HTTP era uma sigla existia só nas maiúsculas, e passar para minúsculas a descartou.

Isso importa ao renomear numa base de código inteira, e é o motivo para converter uma única vez a partir do original em vez de encadear conversões.

Por que existem convenções diferentes

Nenhum desses estilos é melhor que os outros; são acidentes históricos que endureceram em padrões de comunidade. C e seus descendentes no Unix preferiram minúsculas com sublinhado porque os linkers antigos não diferenciavam maiúsculas e nomes longos custavam caro. O Smalltalk popularizou o camelCase, o Java o herdou, e o JavaScript seguiu o Java de perto o suficiente para herdá-lo de novo.

O guia de estilo do Python codificou snake_case para funções e variáveis e PascalCase para classes, e a força desse documento é a razão pela qual o código Python parece consistente entre projetos de um jeito que linguagens mais antigas nunca conseguiram. CSS e HTML ficaram com kebab-case em parte porque suas gramáticas não diferenciam maiúsculas e em parte porque hifens se leem com naturalidade numa linguagem sem identificadores.

A consequência prática é que a convenção certa é a que o ecossistema ao redor usa. Um arquivo Python cheio de camelCase é mais difícil de ler não porque o estilo seja pior, mas porque quebra o padrão que todos os outros arquivos do projeto seguem.

Atravessando a fronteira entre duas convenções

A maioria dos sistemas reais tem ao menos uma emenda em que a convenção muda. Um schema PostgreSQL usa snake_case porque identificadores sem aspas viram minúsculas; a API JSON na frente dele normalmente usa camelCase; o componente React que consome esse JSON usa PascalCase para o componente e camelCase para suas props; e a classe CSS que ele renderiza é kebab-case.

Converter na emenda, num único lugar, é o que mantém isso gerenciável. ORMs e bibliotecas de serialização quase todas oferecem uma configuração de estratégia de nomes exatamente para isso, e usá-la é melhor que mapear cada campo à mão, que é de onde vêm os erros de digitação e as propriedades que somem em silêncio.

O que se deve evitar é converter duas vezes, ou converter nos dois sentidos em camadas diferentes. Quando um campo chega como user_name, vira userName no cliente e volta como userName para uma API que esperava user_name, a divergência costuma aparecer como um valor silenciosamente ignorado, e não como um erro.

Renomear numa base de código sem quebrá-la

Renomear é busca e substituição apenas nos casos mais simples. O mesmo identificador pode aparecer como variável, numa string usada para serialização, numa coluna de banco, num caminho de URL e na documentação, e essas não são todas a mesma mudança - renomear a variável é seguro, renomear a chave serializada é uma quebra de contrato na API.

A ordem que funciona é converter uma vez a partir do original, em vez de encadear conversões, porque siglas não sobrevivem à ida e volta: HTTPServer vira http_server e retorna como HttpServer. Gere o mapeamento inteiro primeiro, revise, depois aplique.

Linters são a correção duradoura. ESLint, Ruff, golint e equivalentes conseguem impor uma convenção de nomes ao código novo, o que impede o problema de voltar depois que a grande renomeação estiver feita.

Maiúsculas e minúsculas não são simples em todo idioma

Converter para maiúsculas ou minúsculas é uma operação dependente de locale, e alguns casos conhecidos quebram código ingênuo. Em turco, a maiúscula de i tem ponto, e passar I para minúscula dá um caractere sem ponto - e é por isso que uma comparação que ignora maiúsculas feita num locale turco pode não casar identificadores idênticos em inglês. A defesa usual é passar para minúsculas com um locale invariante quando o texto é um identificador, e não prosa.

O ß alemão vira SS em maiúsculas, então a operação muda o tamanho da string, e a ida e volta não devolve o original. O sigma grego tem duas formas minúsculas, conforme termine ou não uma palavra. Nada disso afeta identificadores ASCII, que é a maior parte do código, mas tudo isso afeta texto fornecido por usuários.

As conversões aqui operam sobre texto latino e deixam intactos os caracteres japoneses, chineses e coreanos, já que esses sistemas de escrita não têm distinção entre maiúsculas e minúsculas.

O nome é a parte que sobrevive ao código

Converter capitalização é mecânico; escolher as palavras não é, e são as palavras que realmente atrapalham o leitor. Um estilo consistente torna a base de código legível de relance, mas um nome ruim aplicado com consistência continua sendo um nome ruim, e renomear é barato agora e caro depois que o identificador já está numa API, numa coluna de banco e em três dashboards.

Algumas convenções valem o esforço. Booleanos se leem melhor com um prefixo que torne a pergunta explícita - isActive, hasPermission, canEdit - porque um simples active é ambíguo entre estado e ação. Coleções no plural e itens no singular, então users e user em vez de userList. Unidades fazem parte do nome: timeoutMs, sizeBytes, priceCents.

Evite abreviar além do ponto de reconhecimento. As duas letras economizadas em usrMgr custam um instante a cada leitor futuro, e a busca fica pouco confiável quando metade da base escreve user e a outra metade usr. O mesmo vale para sinônimos inconsistentes: fetch, get, load e retrieve fazendo o mesmo trabalho em quatro módulos é um imposto pequeno pago para sempre, e escolher um deles é de graça.