camelCase ou snake_case: qual padrão devo escolher?

Ao desenvolver uma aplicação qualquer sempre vem a dúvida entre usar camelCase ou snake_case, seja para variáveis ou para contratos JSON.

Uma dúvida comum para muitos desenvolvedores de software: usar camelCase ou snake_case, afinal essa escolha irá ditar todo o projeto.

O mais interessante é que não existe um padrão errado ou um certo, a sua escolha vai depender de vários fatores.

Para fazer sua escolha de maneira acerta é preciso analisar o seu projeto como um todo para evitar inconsistências.

camelCase ou snake_case: qual padrão devo escolher?

Para realizar uma boa escolha como padrão para o seu projeto é preciso analisar os seguintes fatores:

• Tecnologia utilizada
• Qual padrão utilizado em aplicações do legado
• Legibilidade pela equipe
• Consistência entre todas as partes do projeto

O que é camelCase?

É um padrão para nomenclatura de variáveis, atributos, métodos e demais objetos de uma linguagem de programação ou banco de dados.

Este padrão obedece os seguintes princípios:

• A primeira letra da primeira palavra é minúscula
• Sem espaço em as palavras que compõe o nome do objeto
• A primeira letra das palavras subsequentes são maiúsculas

Exemplos de nomenclatura camelCase: meuMetodo, minhaVariavelControle, etc.

Este padrão é comumente aplicado em projetos utilizando Java, JavaScript, C# e muitas outras linguagens.

O que é snake_case?

Basicamente, assim como o camelCase, é um padrão para nomenclatura de variáveis, atributos, métodos e demais objetos de uma linguagem de programação ou banco de dados.

Ele obedece os seguintes princípios:

• Todas as palavras que compõe o nome começam com letra minúscula
• Ao invés de espaço é utilizado o under line

Alguns exemplos de nomenclatura neste padrão: meu_metodo, minha_variavel_controle, etc.

É comumente utilizado em Python, Oracle e diversas outras linguagens.

Qual escolher?

Para realizar a melhor escolha temos que ter em mente que não existe padrão certo ou errado, isso é um convenção, porém, uma vez decidida deverá ser seguida em todas as partes envolvidas no projeto.

Antes de decidir devemos avaliar os seguintes pontos:

• Convenção linguagem: o primeiro ponto é verificar qual linguagem será utilizada e qual é a convenção adotada por ela
• Sistemas legado: observer os sistemas e projetos legado onde o seu irá se inserir, mudar de convenção no meio do caminho pode não ser uma boa ideia
• Em todas as partes: comumente os projetos se consistem em banco de dados, backend, frontend e mobile, é importante que todas essas frentes sigam a mesma convenção.