Conversor de Mayúsculas

Los estilos y dónde encaja cada uno

camelCase empieza en minúscula y pone en mayúscula la inicial de cada palabra siguiente; es la convención para variables y funciones en JavaScript, Java y Swift. PascalCase pone también en mayúscula la primera palabra y suele reservarse para tipos, clases y componentes. snake_case une palabras en minúscula con guiones bajos y es el estándar en Python, Ruby, Rust y los identificadores SQL. SCREAMING_SNAKE_CASE es lo mismo en mayúsculas y se usa casi exclusivamente para constantes y variables de entorno.

kebab-case une palabras en minúscula con guiones y corresponde a lugares donde los guiones bajos son incómodos o invisibles: slugs de URL, nombres de clases y propiedades personalizadas de CSS, atributos HTML, opciones de línea de comandos, nombres de paquetes npm. dot.case aparece en claves de configuración y ajustes con espacio de nombres.

Elegir el adecuado rara vez es cuestión de gusto. Cada ecosistema tiene su convención, los linters la imponen y un identificador con el estilo equivocado resulta ajeno en el archivo donde aparece.

Lo difícil es separar las palabras

Convertir entre estilos es fácil cuando sabes dónde están las palabras, y encontrarlas es donde fallan las implementaciones ingenuas. La entrada se divide por guiones bajos, guiones, puntos y espacios, y también por los cambios entre mayúsculas y minúsculas, así que userName y user_name dan las mismas dos palabras.

Las secuencias de mayúsculas se tratan como una sola palabra y no como una palabra por letra. XMLHttpRequest se separa en XML, Http, Request, lo que da xml_http_request y no x_m_l_http_request, y getUserID conserva ID entero. La regla es que una secuencia de mayúsculas termina un carácter antes de una minúscula que la sigue, y eso es lo que hace que la H de Http empiece una palabra nueva en lugar de terminar la anterior.

Los dígitos se unen a la palabra a la que siguen, así que parseInt32 se separa en parse, Int32. Los separadores iniciales y finales se descartan, y los repetidos se fusionan.

Estilos para prosa, y CJK

Title Case no consiste simplemente en poner en mayúscula cada palabra. Las guías de estilo en inglés mantienen en minúscula los artículos, las preposiciones cortas y las conjunciones coordinantes salvo que abran o cierren el título, por eso el resultado es The Lord of the Rings y no The Lord Of The Rings. Las guías no coinciden en dónde está el límite, sobre todo con preposiciones de cuatro letras o más, así que consulta la tuya si importa. Sentence case pone en mayúscula solo la primera palabra y deja el resto, y cada vez más sitios lo usan como estilo para encabezados, igual que es la norma habitual en español.

El japonés, el chino y el coreano no distinguen entre mayúsculas y minúsculas, así que esos caracteres pasan sin cambios. En texto mixto solo se convierten los fragmentos en alfabeto latino. Un fragmento CJK se trata como una sola palabra, porque dividirlo en palabras requiere un diccionario y un segmentador, y adivinar los límites produciría un resultado erróneo con total seguridad.

La conversión de ida y vuelta pierde información

Convertir un identificador a otro estilo y volver no siempre devuelve lo que tenías. De snake_case a camelCase y de vuelta es seguro, porque los límites de los guiones bajos se conservan como cambios de mayúscula. Todo lo que incluya una sigla no lo es: HTTPServer se convierte en http_server, y al volver da HttpServer. La información de que HTTP era una sigla solo existía en las mayúsculas, y pasar a minúsculas la eliminó.

Esto importa al renombrar en todo un código, y es la razón para convertir una sola vez desde el original en lugar de encadenar conversiones.

Por qué existen convenciones distintas

Ninguno de estos estilos es mejor que los demás; son accidentes históricos que se endurecieron hasta convertirse en estándares de comunidad. C y sus descendientes en Unix prefirieron minúsculas con guiones bajos porque los enlazadores antiguos no distinguían mayúsculas y los nombres largos salían caros. Smalltalk popularizó camelCase, Java lo heredó y JavaScript siguió a Java lo bastante de cerca como para heredarlo otra vez.

La guía de estilo de Python fijó snake_case para funciones y variables y PascalCase para clases, y la fuerza de ese documento es la razón por la que el código Python parece consistente entre proyectos de una forma que los lenguajes más antiguos nunca lograron. CSS y HTML acabaron en kebab-case en parte porque sus gramáticas no distinguen mayúsculas y en parte porque los guiones se leen con naturalidad en un lenguaje sin identificadores.

La consecuencia práctica es que la convención correcta es la que usa el ecosistema de alrededor. Un archivo de Python lleno de camelCase cuesta más de leer no porque el estilo sea peor, sino porque rompe el patrón que siguen todos los demás archivos del proyecto.

Cruzar la frontera entre dos convenciones

Casi todos los sistemas reales tienen al menos una costura en la que cambia la convención. Un esquema de PostgreSQL usa snake_case porque los identificadores sin comillas se pasan a minúsculas; la API JSON que está delante suele usar camelCase; el componente React que consume ese JSON usa PascalCase para el componente y camelCase para sus props; y la clase CSS que renderiza es kebab-case.

Convertir en la costura, en un solo sitio, es lo que mantiene esto manejable. Casi todos los ORM y bibliotecas de serialización ofrecen una opción de estrategia de nombres precisamente para esto, y usarla es mejor que mapear cada campo a mano, que es de donde salen las erratas y las propiedades que desaparecen sin avisar.

Lo único que hay que evitar es convertir dos veces, o convertir en ambos sentidos en capas distintas. Cuando un campo llega como user_name, se convierte en userName en el cliente y se devuelve como userName a una API que esperaba user_name, el desajuste suele manifestarse como un valor ignorado en silencio y no como un error.

Renombrar en todo un código sin romperlo

Renombrar es buscar y reemplazar solo en los casos más sencillos. El mismo identificador puede aparecer como variable, en una cadena usada para serializar, en una columna de base de datos, en una ruta de URL y en la documentación, y esas no son todas el mismo cambio: renombrar la variable es seguro, renombrar la clave serializada es un cambio que rompe la API.

El orden que funciona es convertir una sola vez desde el original en lugar de encadenar conversiones, porque las siglas no sobreviven a un viaje de ida y vuelta: HTTPServer se convierte en http_server y vuelve como HttpServer. Genera primero el mapeo completo, revísalo y después aplícalo.

Los linters son la solución duradera. ESLint, Ruff, golint y sus equivalentes pueden imponer una convención de nombres al código nuevo, lo que evita que el problema reaparezca una vez hecho el gran renombrado.

Las mayúsculas no son simples en todos los idiomas

Pasar a mayúsculas o minúsculas es una operación que depende del idioma, y unos cuantos casos conocidos rompen el código ingenuo. En turco, la mayúscula de la i lleva punto, y pasar I a minúscula da un carácter sin punto, y por eso una comparación que ignora mayúsculas hecha en un locale turco puede no emparejar identificadores idénticos en inglés. La defensa habitual es pasar a minúsculas con un locale invariante cuando el texto es un identificador y no prosa.

La ß alemana pasa a SS en mayúsculas, así que la operación cambia la longitud de la cadena y el viaje de ida y vuelta no devuelve el original. La sigma griega tiene dos formas minúsculas según termine o no una palabra. Nada de esto afecta a los identificadores ASCII, que son la mayor parte del código, pero todo ello afecta al texto que escriben las personas.

Las conversiones de aquí operan sobre texto latino y dejan intactos los caracteres japoneses, chinos y coreanos, ya que esos sistemas de escritura no distinguen mayúsculas de minúsculas.

El nombre es lo que sobrevive al código

Convertir el estilo de escritura es mecánico; elegir las palabras no lo es, y son las palabras con las que el lector realmente batalla. Un estilo consistente hace que un código se lea de un vistazo, pero un mal nombre aplicado con consistencia sigue siendo un mal nombre, y renombrar es barato ahora y caro cuando el identificador ya está en una API, en una columna de base de datos y en tres cuadros de mando.

Unas cuantas convenciones compensan. Los booleanos se leen mejor con un prefijo que haga explícita la pregunta - isActive, hasPermission, canEdit - porque un simple active es ambiguo entre estado y acción. Las colecciones en plural y los elementos sueltos en singular, así que users y user en lugar de userList. Las unidades van en el nombre: timeoutMs, sizeBytes, priceCents.

Evita abreviar hasta el punto de no reconocer la palabra. Las dos letras que ahorras en usrMgr le cuestan un instante a cada lector futuro, y la búsqueda deja de ser fiable cuando media base escribe user y la otra media usr. Lo mismo ocurre con los sinónimos inconsistentes: fetch, get, load y retrieve haciendo el mismo trabajo en cuatro módulos es un pequeño impuesto que se paga para siempre, y elegir uno es gratis.