9 de abril de 2012

Debugging Post.1


Debugging é um execício de investigação. Raciocínio dedutivo, observação cuidadosa, lógica abstrata, perseverança e auto-questionamento são todos essenciais. 

Em qualquer projecto de programação, debugging é inevitável. Mesmo um bug simples pode consumir horas, e até mesmo dias de trabalho. É claro que o objectivo é produzir código de maneira a prevenir bugs. O problema é que, muitas vezes, não podemos prevenir bugs até conhece-los. E nós normalmente não os conhecemos até encontra-los e extermina-los pelo menos uma vez.

Talento é essencial no desenvolvimento de um aplicativo, mas é aqui que a experiência compensa, pois o programador experiente não é pego pelo mesmo bug 2 vezes.
Outra parte importante em escrever código de qualidade é mante-lo robusto. Quando mudanças são feitas no código ele não pode parar ou gerar novos bugs. Se o programa não é fácil de manter então estará destinado a uma vida útil muito curta.
Por exemplo: Quando escrevemos funções ou procedimentos em VB, é mais seguro passar parâmetros por valor (ByVal) do que por referência (ByRef) que é o default. Isto assegura que a função não tem como modificar o valor da variável que é passada como parâmetro.

Note que como ByRef é o padrão é uma boa prática adicionar a palavra ByVal a cada novo parâmetro.

ByRef só deve ser usado se você tiver um propósito específico. Uma razão para usa-lo é a função retornar um parâmetro modificado, outra é um pequeno ganho em performance que o ByRef oferece. Entretanto na maioria dos casos o pequeno ganho em rendimento não justifica o risco acarretado pelo uso do ByRef.
Se você usar ByRef o propósito deve ser indicado num comentário.

Os melhores programadores vão "debugando" a medida que programam. Eles não dão um novo passo até que qualquer erro possível de ser antecipado e tratado assim o seja. Quando o programa chega na data limite, este programador pode não estar com todas as rotinas no lugar, mas as que estão funcionam perfeitamente. Isto é preferível a um programa completo que "deixa de responder" quando é executado.

Na arte de achar erros nunca assuma nada. Esta é uma óptima razão para ser sempre explícito.
Sempre use Option Explicit em cada módulo de VB para ter certeza que o programa só rodará se todas as variáveis tiverem sido declaradas. 

Sempre inicialize variáveis e arrays. Nunca confie em valores default. 
Sempre especifique ByVal ou ByRef 
Sempre dimensione ou redimensione arrays explicitamente, indicando o índices do primeiro e do último elemento. 

Estas práticas protegem contra mal entendidos, contra mudanças na linguagem de programação e fazem o código mais legível, auto-suficiente e sem ambiguidade.

Enquanto é importante ter uma resposta rápida em caso de incêndio, é mais importante ter uma prevenção ainda melhor.
No geral, a maior parte da sua atenção enquanto programador deve ser gasta, não criando novas funcionalidades ou tratando erros depois deles terem acontecidos, mas prevenindo-os de acontecer.

Em qualquer ponto do programa onde o usuário pode fazer uma entrada, um erro pode acontecer, quer seja na hora ou um pouco depois. Ao invés de focar em como trata-los tente sempre preveni-los de acontecer.

A prevenção de erros deve acontecer o quanto antes. Por exemplo, uma TextField para a entrada de IDADE. As seguintes regras devem ser implementadas assim que o controle for criado e ter sua função definida (no caso, a entrada de IDADE):

 -Definir a propriedade MaxLength em 2. 
-Filtrar qualquer caracter alfanumérico no evento KeyPress.
-Verificar se exactos 2 caracteres foram digitados no evento LostFocus. 

Em cada um destes tópicos nós estamos prevenindo erros de acontecerem. É claro que nós não podemos prever todos os erros possíveis de acontecer, por isso além da prevenção devemos também nos preocupar com o tratamento depois do erro ter acontecido.

Depois de escrever o código de prevenção de erros e implementa-lo, você deve passar para a parte de captura e tratamento. As vezes é impossível controlar a entrada de dados ou eventos externos que podem fazer com que partes de seu código falhem ao executar. Pegue como exemplo a abertura de um arquivo externo. Você já tomou o cuidado de verificar se o arquivo escolhido existe e está onde deve mas ainda assim você pode incorrer num erro se ele estiver corrupto.