Conversor de Case de Texto: Guia Completo
Convenções de nomenclatura e formatação de texto são cruciais para código legível e manutenível. De camelCase a snake_case, diferentes linguagens e comunidades de programação têm preferências fortes sobre como nomear variáveis, funções e arquivos. Este guia abrangente explica todas as principais convenções de case e quando usar cada uma.
Convenções Comuns de Case
Convenções de case determinam como palavras múltiplas são combinadas em identificadores. Cada convenção tem propósitos específicos, origens históricas e contextos apropriados. Entender estas convenções ajuda você a escrever código idiomático que segue padrões de comunidade. camelCase (dromedaryCase): A primeira palavra é minúscula, palavras subsequentes são capitalizadas. Exemplo: getUserName, calculateTotalPrice, isValidInput. Usado para: variáveis JavaScript, métodos Java, propriedades Swift. Origem: Popularizado por convenções de nomenclatura Java nos anos 1990. As "corcovas" de letras maiúsculas lembram um camelo. PascalCase (UpperCamelCase): Como camelCase mas primeira palavra também capitalizada. Exemplo: UserName, CalculateTotalPrice, IsValidInput. Usado para: nomes de classe em maioria das linguagens OO, componentes React, tipos TypeScript. Também chamado StudlyCase. A distinção de camelCase vs. PascalCase ajuda diferenciar visualmente classes de variáveis. snake_case: Palavras separadas por underscores, tudo minúsculo. Exemplo: get_user_name, calculate_total_price, is_valid_input. Usado para: Python (padrão PEP 8), Ruby, variáveis PHP, nomes de banco de dados SQL. Origem: Convenções Unix/C históricas. O underscore "rastreia" ao longo como uma cobra. SCREAMING_SNAKE_CASE (CONSTANT_CASE): Como snake_case mas tudo maiúsculo. Exemplo: MAX_CONNECTION_TIMEOUT, API_KEY, DATABASE_URL. Usado para: constantes em maioria das linguagens, variáveis de ambiente. A capitalização "grita" que estes valores não devem mudar. kebab-case (dash-case, lisp-case): Palavras separadas por hífens, tudo minúsculo. Exemplo: get-user-name, calculate-total-price, is-valid-input. Usado para: URLs, nomes de arquivo, classes CSS, atributos HTML. Não permitido em maioria das linguagens de programação (hífen é operador de subtração). Chamado kebab-case porque palavras são "espetadas" por hífens como carne em espeto. COBOL-CASE (TRAIN-CASE): Como kebab-case mas tudo maiúsculo. Exemplo: GET-USER-NAME. Usado principalmente em: COBOL legado, alguns cabeçalhos HTTP. Raramente visto em código moderno. flatcase: Tudo junto, sem separadores, tudo minúsculo. Exemplo: getusername, calculatetotalprice. Usado para: alguns comandos Unix, nomes de pacote Java. Geralmente evitado porque difícil de ler. Apenas aceitável para palavras únicas ou pares. Cada convenção serve propósito. Use camelCase para variáveis JavaScript. Use PascalCase para classes. Use snake_case para Python. Use kebab-case para URLs. Consistência dentro de um projeto importa mais que qualquer convenção específica.
Convenções Específicas de Linguagem
Diferentes linguagens de programação têm convenções estabelecidas de nomenclatura. Seguir estas convenções torna seu código idiomático e familiar para outros desenvolvedores na mesma linguagem. JavaScript/TypeScript: variáveis e funções usam camelCase (getUserData, totalCount). Classes e interfaces usam PascalCase (UserService, ApiResponse). Constantes usam SCREAMING_SNAKE_CASE (MAX_RETRIES, API_ENDPOINT). Arquivos geralmente usam kebab-case (user-service.js) ou camelCase (userService.js). Componentes React usam PascalCase (UserProfile.jsx). Python: Variáveis e funções usam snake_case (get_user_data, total_count) por PEP 8. Classes usam PascalCase (UserService, ApiResponse). Constantes usam SCREAMING_SNAKE_CASE (MAX_RETRIES). Módulos/arquivos usam snake_case (user_service.py). Convenções Python são altamente padronizadas—siga PEP 8. Java: Variáveis e métodos usam camelCase (getUserData, totalCount). Classes e interfaces usam PascalCase (UserService, ApiResponse). Constantes usam SCREAMING_SNAKE_CASE (MAX_RETRIES). Pacotes usam lowercase sem separadores (com.example.userservice). Convenções Java são rígidas e universalmente seguidas. C#: Segue convenções similares a Java mas propriedades públicas usam PascalCase (UserName, não userName). Campos privados podem usar camelCase com underscore inicial (_userName) ou apenas camelCase. Métodos usam PascalCase (GetUserData). Constantes usam PascalCase (MaxRetries) ou SCREAMING_SNAKE_CASE. Ruby: Variáveis e métodos usam snake_case (get_user_data, total_count). Classes e módulos usam PascalCase (UserService). Constantes usam SCREAMING_SNAKE_CASE (MAX_RETRIES). Arquivos usam snake_case (user_service.rb). Ruby fortemente prefere snake_case sobre camelCase. Go (Golang): Variáveis e funções privadas usam camelCase (getUserData). Funções e tipos exportados usam PascalCase (GetUserData, UserService). Constantes seguem mesma regra (MaxRetries se exportado, maxRetries se privado). Convenção Go usa capitalização para controlar visibilidade (exportado vs. privado). PHP: Historicamente inconsistente mas moderno PHP usa camelCase para métodos ($getUserData), PascalCase para classes (UserService), snake_case para nomes de banco de dados. Frameworks têm suas próprias convenções—Laravel usa snake_case extensivamente. SQL: Nomes de tabela e coluna tradicionalmente usam snake_case (user_accounts, created_at). Alguns times preferem PascalCase para nomes de tabela (UserAccounts). Convenção varia amplamente—escolha uma e mantenha. Palavras-chave SQL convencionalmente maiúsculas (SELECT, FROM) mas isto é preferência estilística. HTML/CSS: Atributos HTML usam kebab-case (data-user-id, aria-label). Classes CSS usam kebab-case (user-profile, nav-menu). Convenções BEM (Block Element Modifier) usam hífens e underscores (block__element--modifier). Ao trabalhar em projeto existente, sempre siga convenções estabelecidas, mesmo se você prefere diferente. Consistência supera preferência pessoal. Ao iniciar projeto novo, escolha convenções apropriadas para sua linguagem e documente-as.
Melhores Práticas
Além de escolher a convenção de case correta, seguir melhores práticas gerais de nomenclatura melhora legibilidade e manutenibilidade de código. Consistência é suprema. Uma vez que você escolhe convenção, use-a universalmente através de sua base de código. Misturar camelCase e snake_case aleatoriamente causa confusão e parece não profissional. Ferramentas de linting podem enforçar consistência automaticamente—use-as. Seja descritivo mas conciso. Nomes devem claramente indicar propósito sem ser excessivamente verbosos. calculateUserAccountBalance é bom. calc é muito curto. calculateTheCurrentBalanceOfTheUserBankAccount é muito longo. Mire 2-4 palavras para a maioria de identificadores. Use termos específicos de domínio. Em aplicação de e-commerce, Order e Product têm significados específicos. Use-os consistentemente. Não chame pedido de Purchase em um lugar e Order em outro. Prefixos booleanos: Variáveis booleanas devem soar como perguntas. Use is, has, can, should: isValid, hasPermission, canEdit, shouldUpdate. Isto torna condicionais naturais de ler: if (isValid) lê melhor que if (valid). Plurais para coleções: Arrays e listas devem ter nomes plurais. users não user. orderItems não orderItem. Isto torna óbvio que você está lidando com coleção. Evite abreviações a menos que universalmente entendidas. msg para message pode ser OK. usrAcctBal para userAccountBalance não é. Exceções: id, url, api, http são amplamente entendidos. Evite números em nomes (user1, temp2) a menos que significativos (sha256, base64). Números geralmente indicam que você precisa de array ou melhor estrutura de dados. Verbos para funções/métodos: Funções fazem algo, então use verbos. getUserData, calculateTotal, validateInput, renderComponent. Substantivos para variáveis/propriedades: userName, totalPrice, validInput. Convenções de nomenclatura para diferentes escopos: Variáveis locais podem ser mais curtas (i para loops, e para exceções, ctx para contexto). Variáveis globais/públicas devem ser mais descritivas. Variáveis privadas às vezes usam underscore inicial (_privateVariable) embora isto varie por linguagem. Evite palavras reservadas e conflitos. Não nomeie variáveis class, function, import, etc. Enquanto algumas linguagens permitem via escaping, causa confusão. Similarmente, não sombre variáveis embutidas (não nomeie variável string ou date). Considere internacionalização. Palavras em inglês são padrão em programação, mas evite gírias ou termos culturalmente específicos que não traduzem bem. Use termos técnicos universalmente entendidos. Documente convenções em guia de estilo de projeto. Novo desenvolvedores devem ser capazes de aprender convenções de nomenclatura de seu projeto rapidamente. Considere usar EditorConfig, Prettier ou ferramentas similares para enforçar formatação automaticamente.
Testar a Ferramenta
Conversor de Maiúsculas
Saiba Mais
Perguntas Frequentes
Conversor de Maiúsculas
Perguntas Frequentes →