O problema do VBA é o VBA, não a linguagem em si

Tirinha do XKCD
Tirinha do XKCD Transcrição da tirinha: 1 – Você bem pra cama? 2 – Agora não posso. Estou fazendo algo importante 3 – O que? 4 – Alguém na internet está enganado

Título chato não? Eu odeio clickbait e juro que não tentei fazer um. Só mantive porque logo logo fará sentido. Quanto a tirinha no topo do artigo, quase me senti assim ao escrever esse texto, mas é só para dar tom de brincadeira. E NÃO, não acho que o Bill Jelen esteja errado. Só acho que faltou um pouco de contexto. Então, penso nesse texto como um complemento, não como uma resposta.

A discussão é antiga, como tantas outras, mas foi realimentada por este artigo traduzido pelo colega Cristiano Galvão do site/blog/youtube Excel Turbo que vale muito a pena a leitura:

Quando Faz Sentido Usar o Option Explicit

Já leu? Se a resposta for não, volte lá e depois continue lendo este texto. Do contrário, fará pouco sentido.

O argumento é sobre o uso do Option Explicit no VBA. Ele força a declaração de variáveis no contexto do módulo de código. A ausência de declaração fará o programa gerar um erro antes mesmo de executar, o conhecido erro de compilação, algo que os programadores VBA estão pouco acostumados, infelizmente. O autor explica porque antes era contra e porque depois se tornou a favor.

Antes de seguir, um pouco de contexto. Minha principal linguagem de programação no dia a dia é o C#. Ele é por natureza fortemente tipado, ou seja, qualquer coisa que for colocada em memória precisa ser previamente declarada e ter seu tipo definido. Qualquer atribuição indevida causará um erro de compilação. Não declarar variável então…

É natural assumir que, por muito tempo argumentei que linguagens de tipagem forte eram “a coisa correta a se usar”. Qualquer coisa que não isso era demonizada. PHP era o patinho feio da vez e o ASP então. C#, Java e Delphi eram as bolas da vez. As IDEs ficavam cada vez mais ricas e baratas (Eclipse e NetBeans principalmente). Vamos tipar tudo e dar adeus aos problemas de compilação. Deu certo, por um tempo.

Não demorou muito e o mercado, principalmente o web, foi dominado por linguagens como o Ruby, Python, o PHP voltou à tona e o Javascript deu as caras pra valer. O que elas têm em comum? Sim, elas não são linguagens de tipagem forte. Ainda que algumas exijam que você defina uma variável, o tipo dela tanto faz. Ruby e Python, amado por quase todos os programadores que conheço, nem isso. E hoje, algumas delas pagam mais do que as citadas anteriormente, as de tipo de forte tão bravamente defendidas pela turma do Ctrl+Shift+B.

Ok, mas e o VBA?

O que mudou tanto e o que isso tem a ver com o VBA? A partir daqui este texto é de total opinião minha.

O que mudou de lá pra cá que afetou isso foram duas coisas:

  • As IDEs
  • Os frameworks de teste

As IDEs, ou melhor, as ferramentas de codificação evoluiram em níveis absurdos. O que antes só uma ferramenta muito bem paga te dava (Visual Studio, Delphi, JBuilder, FoxPro, [sem links, por favor]) hoje editores de texto quase gratuitos como o Sublime Text, Atom e Visual Studio Code com alguns plugins fazem muito melhor. Mesmo o Visual Studio .NET tem uma versão community gratuita com 100% do poder de fogo de codificação. As versão PRO e acima te dão mais ferramentas de depuração, portanto, não contam.

O que isso muda? Simples. Com algum tempo de experiência, é muito, muito difícil você errar algo porque o editor auto completa no digitar da primeira letra do que seja lá o que você for chamar, variável, método, namespace, módulo, etc. Fora os snippets. Se você teve a chance de usar o Visual Studio codificando em VB.NET, terá a grata surpresa de nunca mais esquecer um bloco If sem um End If, ou um Select sem End Select, ou um With sem End With. O editor estará lá, autocompletando tudo, salvando os calos dos seus dedos e horas de tendinite. E sim caro leitor, o VBA não tem isso.

E os frameworks de teste? Bom, isso passa longe do mundo do VBA, a não ser que você seja um super ultra mega progressista da linguagem e coma RubberDuck com farinha.

O que esses frameworks lhe dão, antes mesmo de uma nova forma de pensar no seu código, é a garantia de que seu ele fará o que tem que fazer, sem dar erros. Claro que a qualidade do teste está relacionada ao bom resultado disso, mas a priori, você está circundando seu código com uma camada de software que pode ser automatizada e que vai garantir que seu código funcione como esperado. E, para esse mecanismo, tanto faz você declarar variáveis ou se sua linguagem tem tipagem forte.

A tipagem forte perdeu valor. De nada vale seu código compilar se ele não faz o que precisa, sem errar. Um sistema feito em Perl (aquela coisa horrorosa) ou no amado Python, ambas não tipadas, vale muito mais do que qualquer código C, C++, C# ou Java, naturalmente tipadas.

Em resumo, tudo ficou mais esperto e automatizado. E o VBA não acompanhou isso.

E o Option Explicit?

A resposta é, você é decide. Eu não uso.  E só o digo porque não lembro a última vez que o ativei, memos ainda um dia em que não usá-lo causou-me algum problema. Acaba então sendo uma questão de gosto.

O que quero deixar claro aqui é, se você não gosta de usar o Option Explicit, vá em frente. Só não ache que você é infalível o suficiente para não precisar dele. Se você gosta, vá em frente. Só não ache que ele vai salvar sua vida em todas as situações só por estar lá.

Comentários

comentários