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.
Top comments (0)