FreeToGenerate.com

Dos bibliotecas populares discrepan en el 1,38% de los identificadores reales, y todas las discrepancias son un dígito.

Detectado como
PascalCase
Dividido en
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 conversión pierde información

Dos o más mayúsculas seguidas son una sigla, y ninguna conversión puede devolverla. Una vez en minúsculas, nada registra qué letras iban en mayúscula.

Convertido y vuelto a convertir, queda como XmlHttpRequest

También disponible en: English · Português · Français · العربية

Convertidor de caso para identificadores

camelCase, PascalCase, snake_case, kebab-case y los demás: detectados, convertidos y con la verdad sobre lo que una conversión destruye.

¿Qué es el caso de un identificador?

El caso de un identificador es la convención con la que un programador une varias palabras en un solo nombre. JavaScript y Java prefieren camelCase, Python y Rust usan snake_case, las clases de CSS y las URL usan kebab-case, los nombres de tipo suelen ir en PascalCase y las constantes, por convención, en SCREAMING_SNAKE_CASE. Todas codifican las mismas palabras; lo único que cambia es cómo se unen.

Esta página detecta en qué convención está ya un nombre, lo convierte a todas las demás y te dice lo que casi ningún convertidor dice: si la conversión pierde información que no vas a poder recuperar.

Es la contraparte para programadores del conversor de mayúsculas de este sitio, que se ocupa de la prosa: mayúscula inicial, tipo título y las reglas de capitalización del idioma. Aquí no hay nada de gramática.

Cómo usarlo

  1. Pega o escribe cualquier identificador. Reconoce camelCase, PascalCase, snake_case, kebab-case, SCREAMING_SNAKE_CASE, Train-Case y dot.case. Una cadena que no encaje en ninguna se declara no reconocida en vez de forzarla a la más parecida.
  2. Mira la división en palabras. Toda conversión son los mismos dos pasos —partir el nombre en palabras y volver a unirlas de otro modo—, así que la lista de palabras te dice exactamente qué cree la herramienta que dice tu nombre. Si la división está mal, todas las conversiones de debajo lo estarán.
  3. Copia la forma que necesites. Cada fila tiene su botón de copia, y la fila que coincide con tu entrada aparece marcada. Debajo, una nota dice si convertir de ida y vuelta devolvería el nombre del que partiste.

Dos bibliotecas, dos respuestas, y la causa son los dígitos

Antes de escribir esto tomamos dos bibliotecas de conversión de caso muy usadas —una específica para casos, la otra las funciones de caso de una biblioteca de utilidades general— y las pasamos por todos los identificadores camelCase y PascalCase declarados en el código de este sitio: 5159 nombres. Discreparon en 71, alrededor del 1,38%.

Todas y cada una de las discrepancias eran un dígito. Una biblioteca deja el dígito pegado a las letras anteriores, así que Base64Tool queda base64_tool; la otra trata el dígito como palabra aparte y produce base_64_tool. Lo mismo con utf8Bytes, rot13, mulberry32 y byAlpha2. Clasificamos las 71 y el residuo fue cero: no había una segunda causa escondida tras la primera.

Ninguna de las dos se equivoca. No hay norma para esto, y las dos lecturas responden a dos ideas razonables de qué es un dígito: parte de una palabra, como el 64 de Base64, o una ficha aparte, como un número de versión. Esta herramienta deja los dígitos pegados, de modo que Base64 es una sola palabra, y conviene saber que la herramienta de un compañero puede no hacerlo.

La consecuencia práctica es pequeña pero afilada: si generas el nombre de una columna a partir del nombre de una clase con una herramienta y consultas esa columna desde código que usa otra, base64_tool y base_64_tool no coincidirán y nada te dirá por qué.

Qué destruye la conversión, y con qué frecuencia

El fallo célebre son las siglas. XMLHttpRequest se convierte en xml_http_request, y al volver sale XmlHttpRequest: las tres mayúsculas han desaparecido y nada en la forma snake_case recuerda que estuvieron ahí. Lo mismo le pasa a parseURL, IOError y APIKey. No es un defecto de ninguna biblioteca en concreto: la información sencillamente no está en la forma intermedia.

Lo que merece añadirse, porque casi nadie lo hace, es cuántas veces eso muerde de verdad. Sobre esos mismos 5159 identificadores, solo cuatro contenían dos o más mayúsculas seguidas —menos de una décima de punto porcentual— y aun así los cuatro sobrevivieron a la ida y vuelta. En este código, el caso con pérdida no se dio ni una sola vez.

Es un solo corpus, y de TypeScript, donde nombres como getElementById son lo normal. Un código Java o C# lleno de HTTPSConnection y XMLParser saldría muy distinto, y no pretendemos lo contrario. Pero el saber popular tiene esto del revés: se describe la conversión como poco fiable cuando la versión honesta es que pierde información en un caso concreto e identificable que resulta raro en el naming moderno.

Hay una segunda mitad que conviene saber. Una vez que un nombre está en snake_case, es estable: volver a convertirlo no cambia nada, y el camelCase que sale de él es el mismo por muchas vueltas que des. La pérdida ocurre una sola vez, a la ida, y nunca más. La regla, pues, es simple: convierte desde tu original cuantas veces quieras, pero no trates un nombre ya convertido como una fuente de la que puedas restaurar.

Límites honestos

La división en palabras es todo el motor, y toma dos decisiones que esta página declara en vez de esconder. Los dígitos quedan pegados a las letras anteriores. Y una racha de mayúsculas seguida de una palabra capitalizada se parte antes de la última mayúscula, de modo que HTTPServer da http y server en lugar de estallar en letras sueltas, que es lo que haría la herramienta sin esa regla y es uno de los casos de sabotaje de la batería de pruebas.

La detección es deliberadamente estricta. Algo como mixed_Snake-kebab no satisface ninguna convención, así que se informa como no reconocido en vez de asignarlo a la más cercana. Un detector que siempre adivina parece más capaz y te dice menos.

Hay una ambigüedad real que no tiene respuesta correcta. Una sola palabra en minúsculas —total, nombre, valor— es a la vez camelCase válido y snake_case válido de una palabra. La herramienta la llama camelCase, porque para un identificador es la lectura más común, pero es una convención y no un hecho.

Por último, esto trabaja con identificadores ASCII. La mayoría de los lenguajes admiten letras más allá de la A-Z en los nombres, y las reglas de rachas de mayúsculas de aquí están escritas para el alfabeto latino. Un nombre en griego o cirílico se partirá por los separadores, pero no por los cambios de caja.

¿Por qué es gratis?

Porque es una expresión regular y una unión de cadenas. Todo se ejecuta en tu navegador, nada de lo que escribes se sube y no hay servidor de por medio para renombrar una variable.

Así que no hay cuenta, ni registro, ni nada reservado. El motor y su batería de pruebas están en el repositorio junto a la página, y las pruebas contrastan sus afirmaciones con los más de 5000 identificadores del propio sitio y no con ejemplos inventados: la misma población de la que salieron las cifras de arriba, de modo que el artículo y las pruebas no pueden separarse.