DEV Community

Verbosidade no Código é uma má Prática?

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.

Image of Timescale

🚀 pgai Vectorizer: SQLAlchemy and LiteLLM Make Vector Search Simple

We built pgai Vectorizer to simplify embedding management for AI applications—without needing a separate database or complex infrastructure. Since launch, developers have created over 3,000 vectorizers on Timescale Cloud, with many more self-hosted.

Read more →

Top comments (0)

Image of Docusign

🛠️ Bring your solution into Docusign. Reach over 1.6M customers.

Docusign is now extensible. Overcome challenges with disconnected products and inaccessible data by bringing your solutions into Docusign and publishing to 1.6M customers in the App Center.

Learn more