Conversor de mayúsculas

A discussão sobre convenção de nomenclatura no desenvolvimento de software é mais antiga do que a maioria imagina — e também mais acalorada. `camelCase` teve suas origens no ambiente Smalltalk nos anos 1970 e ganhou popularidade massiva com Java nos anos 1990, que adotou camelCase para variáveis e métodos como parte de seu guia de estilo oficial. `snake_case` é o favorito de C, Python e Ruby: legível, sem ambiguidade, sem caractere maiúsculo. `PascalCase` é o padrão do C# e de classes em geral na maioria das linguagens tipadas. `kebab-case` é impossível como identificador na maioria das linguagens (o hífen é operador de subtração), então migrou para o domínio de URLs, slugs de CSS e atributos HTML como `data-user-id`.

A escolha de uma convenção não é apenas estética. Ela é uma decisão de legibilidade que afeta toda a equipe que mantém o código. Estudos de usabilidade em código sugerem que `snake_case` pode ser mais legível para humanos porque se assemelha à leitura de palavras separadas — o espaço visual entre as palavras é substituído pelo underscore. `camelCase` exige que o cérebro reconheça as mudanças de capitalização como separadores. `SCREAMING_SNAKE_CASE` é reservado por convenção para constantes globais, uma tradição que vem de C onde `#define MAX_SIZE 100` era o jeito padrão de declarar uma constante. Essas escolhas, codificadas em linters como ESLint, PHPStan e guias como o Google Style Guide e o PSR-12 do PHP, evitam discussões intermináveis em code review.

Para desenvolvedores que trabalham em múltiplos contextos, a conversão entre formatos de nomenclatura é uma tarefa cotidiana. Uma API REST retorna campos em `snake_case` (Python, Rails) e o frontend espera `camelCase` (JavaScript). Um banco de dados usa `SCREAMING_SNAKE_CASE` para colunas e o ORM precisa mapear para PascalCase de classes e camelCase de propriedades. Um arquivo de tradução i18n usa `kebab-case` para chaves e o código TypeScript as acessa como camelCase. Fazer esse mapeamento manualmente para dezenas ou centenas de campos é exatamente o tipo de trabalho repetitivo que uma ferramenta automatiza bem.

Esta ferramenta converte blocos de texto completos entre os estilos de capitalização mais comuns: minúsculas, MAIÚSCULAS, Título, `camelCase`, `PascalCase`, `snake_case`, `kebab-case` e `SCREAMING_SNAKE_CASE`. A detecção de separadores de palavra funciona reconhecendo espaços, underscores, hífens e transições de maiúscula para minúscula. Para casos Unicode — nomes próprios em idiomas com scripts não latinos ou siglas misturadas ao código — pode ser necessário revisar o resultado, especialmente em conversões que envolvem capitalização.

The debate over naming conventions in software development is older than most people realize — and more heated too. `camelCase` has its roots in the Smalltalk environment of the 1970s and gained mass popularity with Java in the 1990s, which adopted camelCase for variables and methods as part of its official style guide. `snake_case` is the favorite of C, Python, and Ruby: readable, unambiguous, no uppercase characters. `PascalCase` is the standard for C# and classes in general in most typed languages. `kebab-case` is impossible as an identifier in most languages (the hyphen is a subtraction operator), so it migrated to the domain of URLs, CSS slugs, and HTML attributes like `data-user-id`.

Choosing a convention is not purely aesthetic. It is a readability decision that affects the entire team maintaining the code. Usability studies on code suggest that `snake_case` may be more readable for humans because it resembles reading separate words — the visual space between words is replaced by an underscore. `camelCase` requires the brain to recognize capitalization changes as separators. `SCREAMING_SNAKE_CASE` is reserved by convention for global constants, a tradition rooted in C where `#define MAX_SIZE 100` was the standard way to declare a constant. These choices, codified in linters like ESLint and PHPStan and style guides like the Google Style Guide and PHP's PSR-12, prevent endless discussions during code review.

For developers working across multiple contexts, converting between naming formats is a daily task. A REST API returns fields in `snake_case` (Python, Rails) and the frontend expects `camelCase` (JavaScript). A database uses `SCREAMING_SNAKE_CASE` for columns and the ORM needs to map to PascalCase for classes and camelCase for properties. An i18n translation file uses `kebab-case` for keys and the TypeScript code accesses them as camelCase. Doing that mapping manually for dozens or hundreds of fields is exactly the kind of repetitive work that a tool automates well.

This tool converts full blocks of text between the most common capitalization styles: lowercase, UPPERCASE, Title Case, `camelCase`, `PascalCase`, `snake_case`, `kebab-case`, and `SCREAMING_SNAKE_CASE`. Word boundary detection works by recognizing spaces, underscores, hyphens, and transitions from uppercase to lowercase. For Unicode edge cases — proper nouns in languages with non-Latin scripts or identifiers with mixed acronyms — the result may need manual review, especially for conversions involving capitalization.

El debate sobre las convenciones de nomenclatura en el desarrollo de software es más antiguo de lo que la mayoría imagina — y también más acalorado. `camelCase` tiene sus raíces en el entorno Smalltalk de los años 70 y ganó popularidad masiva con Java en los 90, que adoptó camelCase para variables y métodos como parte de su guía de estilo oficial. `snake_case` es el favorito de C, Python y Ruby: legible, sin ambigüedades, sin mayúsculas. `PascalCase` es el estándar de C# y de las clases en general en la mayoría de los lenguajes tipados. `kebab-case` es imposible como identificador en la mayoría de los lenguajes (el guión es el operador de resta), así que migró al dominio de las URLs, los slugs de CSS y los atributos HTML como `data-user-id`.

Elegir una convención no es solo una cuestión estética. Es una decisión de legibilidad que afecta a todo el equipo que mantiene el código. Los estudios de usabilidad en código sugieren que `snake_case` puede ser más legible para los humanos porque se asemeja a leer palabras separadas — el espacio visual entre las palabras se sustituye por el guión bajo. `camelCase` requiere que el cerebro reconozca los cambios de capitalización como separadores. `SCREAMING_SNAKE_CASE` está reservado por convención para las constantes globales, una tradición arraigada en C donde `#define MAX_SIZE 100` era la forma estándar de declarar una constante. Estas elecciones, codificadas en linters como ESLint y PHPStan y guías como el Google Style Guide y el PSR-12 de PHP, evitan discusiones interminables durante la revisión del código.

Para los desarrolladores que trabajan en múltiples contextos, convertir entre formatos de nomenclatura es una tarea cotidiana. Una API REST devuelve campos en `snake_case` (Python, Rails) y el frontend espera `camelCase` (JavaScript). Una base de datos usa `SCREAMING_SNAKE_CASE` para las columnas y el ORM necesita mapear a PascalCase para clases y camelCase para propiedades. Un archivo de traducción i18n usa `kebab-case` para las claves y el código TypeScript accede a ellas como camelCase. Hacer ese mapeo manualmente para docenas o cientos de campos es exactamente el tipo de trabajo repetitivo que una herramienta automatiza bien.

Esta herramienta convierte bloques completos de texto entre los estilos de capitalización más comunes: minúsculas, MAYÚSCULAS, Título, `camelCase`, `PascalCase`, `snake_case`, `kebab-case` y `SCREAMING_SNAKE_CASE`. La detección de límites de palabras funciona reconociendo espacios, guiones bajos, guiones y transiciones de mayúscula a minúscula. Para casos Unicode — nombres propios en idiomas con escrituras no latinas o identificadores con acrónimos mezclados — puede ser necesario revisar el resultado, especialmente en conversiones que implican capitalización.