Sabemos que instrução GoTo do VBA proporciona uma forma de desviar o fluxo execução de uma função para qualquer linha dentro desta.

Apesar de considerar um recurso útil, as boas práticas de programação condenam o uso deste tipo de instrução. É estranho existir a motivação para a não utilização de um recurso, sendo que por algum motivo ele existe, porém, os argumentos para o caso do GoTo são justificáveis.

Vamos assumir que precisássemos construir um algoritmo (entenda algoritmo como uma sequência de passos definidos para executar uma determinada tarefa) para resolver um problema. A sequência correta de passos para construção deste, seguiria uma estrutura sequêncial bem definida, capaz de ser representada por um fluxograma, por exemplo:

O fato de poder ser representada por um fluxograma, significa que não existe ambiguidade em sua estrutura. Todos os passos para execução das tarefas e tomadas de decisão estão bem definidas, detalhadas e cobrem todas as possibilidades dentro de seu contexto.

Dentro do VBA, as instruções de controle de fluxo como If…Then…Else, While…Wend, For…Next e outras, seguem uma estrutura bem definidas, tendo começo, meio e fim bem localizados em suas definições e utilização. Em todas estas, todos os desvios são previstos e controlados pelo programador. Todos os testes são explícitos baseadas nas condições colocadas. Não há ambiguidade em seu funcionamento.

Neste ponto, a própria definição do GoTo nos leva a pensar:

“É um desvio incondicional para uma linha especificada dentro de uma função VBA.”

A palavra incondicional foi evidenciada propositalmente. Um desvio incondicional de código significa que, sem qualquer critério, condição ou mesmo teste, a instrução GoTo efetua o devio da execução do código para outra linha.

Supondo que a instrução GoTo seja utilizada em uma parte do código em que uma variável estiver com um valor inválido, um valor não esperado ou mesmo não tenha nenhum valor configurado, isso trará problemas para a execução do código, podendo gerar erros. Pior ainda, o código pode até não gerar um erro, mas pode executar suas funções com valores indesejados, levando a resultados desastrosos. Não há teste ou condição que avalie este desvio de execução.

O programador pode em alguns casos fazer as verificações necessárias para evitar algumas inconsitências, porém, a lógica de seu algoritmo será completamente quebrada por conta da não condicionalidade do desvio do GoTo. A situação é mais complicada quando o GoTo devia o fluxo de execução para uma linha anterior a qual ele é invocado.

Um teste simples para verificar o “estrago” que o uso indiscriminado do GoTo é tentar construir um fluxograma simples de sua função com sua sequência de execução.

A única excessão do bom uso do GoTo é para o tratamento de erros utilizando a estrutura On Error GoTo, como pode ser visto neste link.

Recomendações

Como o VBA oferece estruturas de controle de fluxo bem definidas e organizadas, tanto voltadas a lógica simples de teste como também de repetição de coleções (For…Each), é aconselhável sempre utilizar estas estruturas na construção de códigos. Raras serão as excessões em que o uso do GoTo torna-se indispensável. Caso esta situação ocorra, utilize-o com critério, certificando que em nenhuma situação o desvio causado pode afetar o funcionamento de seu algoritmo.

A idéia não é impedir ou condenar o uso do GoTo, até porque, se não fosse útil ele sequer existiria. O principal objetivo deste texto é alertar para os cuidados que devem ser tomados com o uso desta instrução, de forma a manter o controle de seu aplicativo e facilitar, ou até mesmo possibilitar futuras manutenções.