Variáveis Locais Deveriam ter Nomes Curtos


Já pensou que você pode estar dificultando a leitura do seu código por utilizar nomes mais longos e verbosos em variáveis locais do que utilizando nomes mais curtos?

Unsplash image
Photo by chuttersnap on Unsplash

Nomenclatura é quase uma arte, especialmente no desenvolvimento de software.

Escolher bons nomes irá deixar seu código mais legível e isso será imprescindível para a manutenção do mesmo no longo prazo.

Entretanto, um bom nome não quer dizer um nome mais longo e verboso.

Um bom nome irá depender de alguns fatores. Por exemplo: se o nome identificar uma variável de índice para um loop, a maioria dos programadores irá utilizar “i”.

Por quê “i” e não “index”, já que este último é mais explícito?

É claro que haverá todo tipo e código, todo tipo de nomenclatura. Mas, me refiro a maioria. E a maioria utiliza “i” para a nomenclatura de variáveis de índices.

E se quisermos nos referir a uma posição na tela? Eu diria que a nomenclatura mais utiliza é “x,y”. Podemos declarar um record ou classe como TPoint mas é bem provável que seus atributos sejam X e Y.

“Convenção” — você diria.

Sim, convenção, porém eu acho que o motivo está além disso.

Trata-se de legibilidade.

Quando estamos trabalhando em um contexto bem menor, como a implementação de um método por exemplo, não precisamos de nomes longos e verbosos. Sabemos o que X e Y significam; sabemos que “i” é o índice de um loop; sabemos que “s1” e “s2” (provavelmente) significam strings 1 e 2, respectivamente.

Não me entenda mal. Não estou dizendo que todas as variáveis locais devem ter apenas uma ou duas letras. Depende. E talvez não haja uma regra para determinar qual nomenclatura mais adequada, uma regra que abrange todos os casos possíveis. Mas podemos utilizar o bom senso.

Sugiro que os nomes sejam os menores possíveis, porém sem haver ambiguidades. Por exemplo: seria estranho haver duas variáveis assim:

var
  s1: string;      
  s2: TStream;

São dois tipos completamente diferentes, porém utilizando a mesma nomenclatura. É ambíguo e confuso. Por quê s2 representa o TStream e não s1? Falta lógica.

Porém ainda assim, na minha opinião, ainda seriam melhores que isso:

var
  ClientNameTrimed: string;      
  ClientReturnedAsStream: TStream;

O motivo é simples: se você está nomeando suas variáveis de forma tão longa, é por quê o método está fazendo coisas demais e você precisa identificar cada variável — talvez existam mais de cinco — como única para tentar melhorar a legibilidade do método, mas ignorando os indícios de que o método deveria ser refatorado (dividido) em partes menores. Métodos menores poderiam ter menos variáveis, com nomenclatura mais simples.

Seguindo o primeiro exemplo, podemos refatorar as variáveis:

var
  str: string;      
  stm: TStream;

Apesar de ainda haver certa ambiguidade — str ainda poderia ser considerada uma abreviação de TStream — a legibilidade é melhor. Poderíamos simplificar, refatorando str para apenas s já que trata-se de um tipo primitivo, aplicando a lógica de que “tipos primitivos estão abaixo de classes” e, portanto, utilizam menos caracteres…

O importante é haver alguma lógica de nomenclatura entre a equipe.

Outro exemplo de nomenclatura interessante é dar nomes próprios às variáveis, quando estas são do tipo interface ou classe. Vejamos:

var
  bob: TStream;      
  john: TStream;

Temos 2 streams e, ao invés de nomear como stm1 e stm2 ou algo parecido, apenas damos nomes próprios e curtos, de fácil memorização.

Uma vez que seu cérebro já sabe que bob contém a entrada de dados (apenas um exemplo) e john irá conter a saída processada, seria mais difícil esquecer dos nomes comparado a stm1 e stm2.

Mantenha os nomes de variáveis locais o mais curto possível.

Essa é a minha sugestão.

Até logo.

Posts Relacionados

  • Tipo object Continua Vivo

  • Array de Objetos

  • Como Dividir e Organizar o Código em Formulários com Muitos Widgets

  • Pascal Deveria ser Modernizado?

  • Records - Antiga Nova Tecnologia

  • Builder Classes Simplificado

  • Como Transformar uma Instância de Classe em Instância de Interface

  • Interfaces e Casting

  • Como Trabalhar com Libraries sem Pacotes

  • Quem é o Responsável por Liberar os Objetos?