Toda linguagem de programação tem um conjunto de normas que se destinam a trazer um nível de consistência para a construção de uma aplicação. Estes padrões incluem coisas como a nomeação , capitalização e ortografia de nomes de variáveis ​​, padrões de recuo , e padrões de documentação . Enquanto um programador novato pode considerar esses padrões para ser um incômodo demorado, o programador experiente sabe que essas normas aumentar a compreensibilidade e diminuir o tempo de manutenção . Visual Basic tem seu próprio conjunto de padrões de programação para ajudar o programador na construção de aplicações sustentáveis ​​sólidos. Documentação Geral Programa

As primeiras linhas do programa deve incluir "Observações" linhas ( consulte "Adicionar Comentários" ), que identificam o nome do projeto , o autor do programa, a data de criação e uma descrição do aplicativo . Esta é a documentação padrão para qualquer linguagem de programação , uma vez que auxilia o programador de manutenção na identificação do autor original, o que pode economizar horas de tempo de pesquisa.
Variáveis ​​Nomeando

É muito importante que você siga um bom conjunto de convenções de nomenclatura para as variáveis ​​de modo que você será capaz de saber o que você está olhando para quando você está tentando desesperadamente para depurar o programa . Não inclua pontuação ou espaços em seus nomes de variáveis ​​, e não usam Visual Basic palavras reservadas como nomes de variáveis ​​ou VB vontade sinalizá-las como um problema. Use Camel Casing (às vezes chamado Pascal Casing ) para nomear suas variáveis ​​. Este se refere à prática de capitalizar a primeira letra de cada nova palavra em um nome de variável. Aqui estão alguns exemplos :

BankBalanceDecimal

CheckNumberInteger

TotalDepositsDecimal

Observe que a última palavra no nome da variável denota seu tipo de dados . Isso não é necessário , mas é muito útil quando se tenta encontrar um bug de programação indescritível. Claro que há flexibilidade neste , uma vez que VB não impõe suas normas. Se você decidir que o seu padrão irá incluir um sublinhado entre cada palavra em um nome de variável , em seguida, ficar com o padrão. É importante entender que a consistência em seguir os padrões de programação estabelecida é a chave.
Naming componentes formam

Atribuindo nomes para formar componentes (ou controles ) tais como botões, rótulos e caixas de texto , também deve seguir um padrão. Deixando os nomes padrão de "Button1 " e " Label1 " nunca deve ser considerada uma opção viável como ele vai fazer a depuração de uma tarefa frustrante na melhor das hipóteses . Enquanto você pode optar por seguir o mesmo padrão de nomes como os nomes de variáveis ​​que pode ser confuso para escolher uma modificação deste seria aceitável e potencialmente útil . Por exemplo, colocar um sublinhado entre cada palavra em um nome de controle facilmente o identifica como um controle. Aqui estão alguns exemplos de nomes de controle :

Calculate_Button

Name_TextBox

Blue_Radiobutton

Esta pequena diferença rapidamente diferencia um nome do componente a partir de um nome de variável e pode ajudar reduzir a confusão quando a manutenção , teste e depuração.

Instruções executáveis ​​

Cada linha executável deve ser sua própria linha , a menos que é muito grande para caber em uma linha e tem que ser continuado. Neste caso, você deve recuar a linha de um guia para facilitar a leitura continuou . Não combinar várias instruções executáveis ​​em uma linha. Embora o Visual Basic permite isso usando dois pontos (:) como separador , não é boa prática de programação , já que a segunda afirmação pode ser facilmente esquecido . Lembre-se, a legibilidade e inteligibilidade é a meta , ao invés de minimizar o número de linhas de código em seu programa.
Observações Demonstrações

A " observação" (ou "Comment " ) declaração começa com um apóstrofo (' ) e é uma declaração não- executável. Cada procedimento deve conter uma declaração observação como a primeira linha (ou linhas ) explicando brevemente o que o procedimento faz . Embora o Visual Basic muda a cor das observações de verde, é uma boa prática para incluir uma observação em branco como a primeira linha e uma observação em branco como a última linha da seção de comentários de um procedimento. Isso aumenta a legibilidade e reduz a tarefa de separar o código executável a partir de observações .