O conceito mais importante em Informática, para os programadores, é o de variável; pois como não conhece os endereços reais da memória RAM, o programador usa esse conceito para alocar temporariamente os dados, processá-los e/ou exibi-los durante o tempo em que o sistema estiver ativo.

Formalmente, as variáveis devem ser entendidas como "áreas de memória definidas para armazenar dados, visíveis num determinado trecho de um programa e por um determinado período de tempo". Nos tempos áureos do BASIC era "moleza"(!) criar um programa; bastava sair atribuindo valores às variáveis, fazer alguns cálculos, imprimir e pronto! Essa mania passou para o dBase e contaminou os incautos programadores Clipper - notoriamente nas versões Autumn ’86 e Summer ’87. O que queremos é alertar sobre o uso incorreto de variáveis de memória, visto que podem corromper e violar seriamente os princípios da Programação Modular e do encapsulamento, além de diminuir a performance dos programas. Infelizmente, esse fato não raramente passa despercebido pela maioria dos programadores e mesmo pelos autores de livros didáticos(!) sobre linguagens de programação. A partir da versão 5.0 o Clipper adicionou à sua arquitetura mais dois tipos de variáveis de memória: Local e Estática, declaradas com os comandos LOCAL e STATIC, respectivamente. Essas variáveis, assim declaradas, são denominadas Variáveis de Abrangência Léxica, e devem ser preferencialmente utilizadas nas rotinas. Os outros dois tipos de variáveis são as Privadas e as Públicas, declaradas através dos comandos PRIVATE e PUBLIC; elas têm Abrangência Dinâmica e devem ser evitadas ao máximo pelos programadores; essa última, Pública, já era considerada "marginal" na Summer ’87, então na versão 5.x só deve ser usada em último caso! A encrenca toda começa quando o programador declara uma variável do tipo PRIVATE ou PUBLIC e seu nome é colocado numa lista denominada Tabela de Símbolos; assim sendo, toda vez que o programa acessa essa variável o Clipper pesquisa tal tabela para encontrar seu nome; em seguida verifica onde seu valor está armazenado, move-se para o endereço e só então carrega esse valor. Por tudo isso o processo tem de ser atrasado até a execução, o que torna o processamento mais lento. Além disso, esse tipo de variável sempre "engorda" o módulo executável em memória, o que piora ainda mais a performance do sistema. Já com as variáveis de Abrangência Léxica (Local ou Estática) tais problemas não ocorrem, pois além de não ocuparem espaço na Tabela de Símbolos, também não causam aumento do módulo executável em memória; isto porque são resolvidas em tempo de compilação. Por conseguinte, o uso de variáveis Locais (ou Estáticas) torna o processamento mais rápido, além de possibilitar a Programação Modular e encapsular a rotina. E quando o programador não declara a variável?! Bem, aí no caso do Clipper, ela será considerada do tipo PRIVATE, o que retorna à discussão anterior: a performance cai em cerca de 60 % .

Agora os tempos são outros, mas o problema continua o mesmo; pois com o advento do Windows^tm surgiram as ferramentas tipo RAD que nos permite desenvolver sistemas para ambientes gráficos e orientados a eventos. Exemplos mais comuns desse tipo de ferramenta são o Visual Basic e o Delphi.; a primeira é baseada na linguagem BASIC e a segunda no Object Pascal. Desse modo, o perigo de não declarar variável nos programas escritos em Visual Basic (até a versão 6) é permanente para o programador, o que não acontece com o Delphi, devido à sua linguagem primitiva (o Pascal). Como o VB é baseado na linguagem BASIC (bastante liberal), a tendência é a de que os programadores (por comodidade) não declarem corretamente as variáveis. Entretanto, o VB necessita tipar (mesmo que de leve - até a versão 6) suas variáveis; e para isto sempre considera uma variável não declarada como sendo do tipo Variant (que serve para qualquer tipo de dado). É aí que "mora o perigo", pois esse tipo de dado reserva 16 bytes na memória para armazenar um valor, seja ele de qualquer magnitude; e se for uma sequência de caracteres gastará 1 byte extra para cada um desses caracteres. Por tudo isso o sistema fica muito lento, com sua performance caindo assustadoramente. A interface da figura 1 ilustra um exemplo de como podemos checar isso de modo bem prático; e as duas procedures-eventos da Figura 2 mostram como o VB trata de forma diferente as duas situações: quando declaramos variáveis e quando não as declaramos. O âmago da rotina apresentada é o "loop" do tipo FOR...NEXT que conta de 1 até 1000000; temos duas situações a considerar: na procedure do evento Click do botão cmdSemDeclara não declaramos nenhuma variável e na procedure do evento Click do botão cmdComDeclara todas as variáveis foram corretamente declaradas. Os tempos gastos (em segundos) para o processamento, nas duas situações, são colocadas nas duas respectivas caixas de texto: txtSemDeclara e txtComDeclara. Executem esse programa considerando as duas situações e comparem os resultados. Se essa comparação for feita quando rodarem o programa pelo seu executável aí é que a diferença no tempo de processamento chega a ser muito grande, como mostra o exemplo da figura 1. Por isso meus amigos, mesmo se for opcional, procurem sempre declarar todas as variáveis envolvidas nas rotinas.

Figura 1 - Tempos de processamento