Uma das actividades mais difíceis do desenvolvimento de software é dar nome às coisas.

Quais coisas devemos dar nomes? Pacotes, namespaces, classes, objectos, structs, tabelas de base de dados.

Mas, na medida em que o software cresce, os nomes vão ficando escassos, os contextos cruzam-se e as boas práticas...

Segundo as práticas de Nomenclatura

Segundo alguns livros, blogs e artigos, a verbosidade é considerada uma má prática. Mas a maioria dos exemplos nesses blogs e livros são baseados em problemas simples.

Os problemas apresentados não possuem as particularidades dos problemas reais, como processos complexos, nomes iguais em pacotes diferentes e atributos que devem ser escritos conforme os requisitos. O máximo que alcançam é o foco em nomes curtos.

Cenário Real

O cenário real do desenvolvimento de software é diferente.

O tamanho dos nomes é directamente proporcional ao tamanho do projecto.

No caso das aplicações corporativas, é comum a existência de nomes grandes, pois adicionam mais contexto à classe, operação ou processo.

Projectos Grandes

Durante muito tempo, a verbosidade era atribuída a linguagens corporativas como Java e C#, devido à natureza das aplicações dessas plataformas (aplicações corporativas).

Actualmente, se inspecionarmos códigos de projectos em Python, PHP e Go, veremos nomes grandes usados com um propósito específico.

Se analisarmos grandes projectos open-source, independentemente da linguagem, veremos nomes grandes. Ex.: odoo em Python.

Vantagens da Verbosidade

• Nomes significativos.
• Nomes que se encaixam no contexto do negócio.
• Facilidade de manutenção do código (na maioria dos casos).
• Padronização em termos de sufixos e prefixos nos nomes.
• Facilidade na navegação do código (ex.: pacotes, namespaces, etc.).

Desvantagens

• Para bibliotecas com funções simples, pode ser desnecessária.
• Dificuldade de leitura, principalmente em CamelCase, em casos extremos.
• Aumento da carga cognitiva.

Sugestão

Devemos balancear o tamanho dos nomes de identificadores.

Usar nomes muito pequenos ou grandes pode representar vantagens ou desvantagens, dependendo do problema.

No caso de aplicações corporativas, é recomendado usar nomes com mais contexto. Por outro lado, para bibliotecas de utilitários (helpers), é recomendado usar nomes mais directos, que representem a operação.