FreeToGenerate.com

Duas bibliotecas populares divergem em 1,38% dos identificadores reais, e todas as divergências são um algarismo.

Detectado como
PascalCase
Dividido em
3 · xml http request
  • camelCasexmlHttpRequest
  • PascalCase ·XmlHttpRequest
  • snake_casexml_http_request
  • kebab-casexml-http-request
  • SCREAMING_SNAKE_CASEXML_HTTP_REQUEST
  • Train-CaseXml-Http-Request
  • dot.casexml.http.request

Esta conversão perde informação

Duas ou mais maiúsculas seguidas são uma sigla, e nenhuma conversão a devolve. Depois de passar a minúsculas, nada regista que letras estavam em maiúscula.

Convertido e convertido de volta, fica XmlHttpRequest

Também disponível em: English · Español · Français · العربية

Conversor de caso para identificadores

camelCase, PascalCase, snake_case, kebab-case e os restantes: detectados, convertidos e com a verdade sobre o que uma conversão destrói.

O que é o caso de um identificador

O caso de um identificador é a convenção com que um programador junta várias palavras num único nome. O JavaScript e o Java preferem camelCase, o Python e o Rust usam snake_case, as classes de CSS e os URL usam kebab-case, os nomes de tipo costumam ir em PascalCase e as constantes, por convenção, em SCREAMING_SNAKE_CASE. Todas codificam as mesmas palavras; só muda a forma de as juntar.

Esta página detecta em que convenção um nome já está, converte-o para todas as outras e diz-lhe aquilo que quase nenhum conversor diz: se a conversão perde informação que não vai conseguir recuperar.

É a contraparte para programadores do conversor de maiúsculas deste sítio, que trata da prosa — maiúscula inicial, tipo título e as regras de capitalização da língua. Aqui não há nada de gramática.

Como usar

  1. Cole ou escreva qualquer identificador. Reconhece camelCase, PascalCase, snake_case, kebab-case, SCREAMING_SNAKE_CASE, Train-Case e dot.case. Uma cadeia que não encaixe em nenhuma é declarada não reconhecida em vez de forçada à mais parecida.
  2. Veja a divisão em palavras. Toda a conversão são os mesmos dois passos — partir o nome em palavras e voltar a juntá-las de outra maneira — portanto a lista de palavras diz-lhe exactamente o que a ferramenta julga que o seu nome diz. Se a divisão estiver errada, todas as conversões abaixo também estarão.
  3. Copie a forma de que precisa. Cada linha tem o seu botão de cópia, e a linha que corresponde ao que escreveu aparece assinalada. Por baixo, uma nota diz se converter de ida e volta devolveria o nome de que partiu.

Duas bibliotecas, duas respostas, e a causa são os algarismos

Antes de escrever isto pegámos em duas bibliotecas de conversão de caso muito usadas — uma específica para casos, a outra as funções de caso de uma biblioteca de utilitários geral — e passámo-las por todos os identificadores camelCase e PascalCase declarados no código deste sítio: 5159 nomes. Divergiram em 71, cerca de 1,38%.

Todas e cada uma das divergências eram um algarismo. Uma biblioteca deixa o algarismo colado às letras anteriores, portanto Base64Tool fica base64_tool; a outra trata o algarismo como palavra à parte e produz base_64_tool. O mesmo com utf8Bytes, rot13, mulberry32 e byAlpha2. Classificámos as 71 e o resíduo foi zero: não havia uma segunda causa escondida por trás da primeira.

Nenhuma das duas está errada. Não há norma para isto, e as duas leituras correspondem a duas ideias razoáveis do que é um algarismo: parte de uma palavra, como o 64 de Base64, ou uma unidade à parte, como um número de versão. Esta ferramenta mantém os algarismos colados, de modo que Base64 é uma só palavra, e vale a pena saber que a ferramenta de um colega pode não fazer o mesmo.

A consequência prática é pequena mas afiada: se gerar o nome de uma coluna a partir do nome de uma classe com uma ferramenta e consultar essa coluna a partir de código que usa outra, base64_tool e base_64_tool não coincidem e nada lhe dirá porquê.

O que a conversão destrói, e com que frequência

A falha célebre são as siglas. XMLHttpRequest converte-se em xml_http_request, e ao voltar sai XmlHttpRequest: as três maiúsculas desapareceram e nada na forma snake_case regista que ali estiveram. O mesmo acontece a parseURL, IOError e APIKey. Não é um defeito de nenhuma biblioteca em particular: a informação simplesmente não está na forma intermédia.

O que merece ser acrescentado, porque quase ninguém o faz, é quantas vezes isso morde de facto. Sobre esses mesmos 5159 identificadores, apenas quatro continham duas ou mais maiúsculas seguidas — menos de um décimo de ponto percentual — e ainda assim os quatro sobreviveram à ida e volta. Neste código, o caso com perda não ocorreu uma única vez.

É um só corpus, e de TypeScript, onde nomes como getElementById são o normal. Um código Java ou C# cheio de HTTPSConnection e XMLParser sairia muito diferente, e não pretendemos o contrário. Mas o saber corrente tem isto ao contrário: descreve-se a conversão como pouco fiável quando a versão honesta é que perde informação num caso concreto e identificável que é raro na nomenclatura moderna.

Há uma segunda metade que convém saber. Assim que um nome está em snake_case, é estável: voltar a convertê-lo não muda nada, e o camelCase que dele sai é o mesmo por muitas voltas que dê. A perda acontece uma só vez, à ida, e nunca mais. A regra é portanto simples: converta a partir do seu original as vezes que quiser, mas não trate um nome já convertido como uma fonte de onde possa restaurar.

Limites honestos

A divisão em palavras é todo o motor, e toma duas decisões que esta página declara em vez de esconder. Os algarismos ficam colados às letras anteriores. E uma sequência de maiúsculas seguida de uma palavra capitalizada parte-se antes da última maiúscula, de modo que HTTPServer dá http e server em vez de rebentar em letras soltas — que é o que a ferramenta faria sem essa regra, e é um dos casos de sabotagem da bateria de testes.

A detecção é deliberadamente estrita. Algo como mixed_Snake-kebab não satisfaz convenção nenhuma, portanto é reportado como não reconhecido em vez de atribuído à mais próxima. Um detector que adivinha sempre parece mais capaz e diz-lhe menos.

Há uma ambiguidade genuína que não tem resposta certa. Uma só palavra em minúsculas — total, nome, valor — é ao mesmo tempo camelCase válido e snake_case válido de uma palavra. A ferramenta chama-lhe camelCase, por ser a leitura mais comum num identificador, mas é uma convenção e não um facto.

Por fim, isto trabalha com identificadores ASCII. A maioria das linguagens admite letras para além do A-Z nos nomes, e as regras de sequências de maiúsculas aqui estão escritas para o alfabeto latino. Um nome em grego ou cirílico será partido pelos separadores, mas não pelas mudanças de caixa.

Porque é grátis

Porque é uma expressão regular e uma junção de texto. Tudo corre no seu navegador, nada do que escreve é enviado e não há servidor pelo meio para mudar o nome de uma variável.

Portanto não há conta, nem registo, nem nada guardado atrás de um. O motor e a sua bateria de testes estão no repositório ao lado da página, e os testes confrontam as suas afirmações com os mais de 5000 identificadores do próprio sítio e não com exemplos inventados: a mesma população de onde saíram os números acima, de modo que o artigo e os testes não se podem separar.