Hvert programmeringssprog har nogle sæt standarder , der er beregnet til at bringe en grad af konsekvens til opførelsen af en ansøgning . Disse standarder omfatter sådanne ting som navngivning , kapitalisering og stavemåde af variabelnavne , indrykning standarder og dokumentation standarder. Mens en rookie programmør kan overveje disse standarder for at være en tidskrævende gider, den erfarne programmør ved , at disse standarder øge forståelighed og fald vedligeholdelse tid. Visual Basic har sit eget sæt af programmering standarder for at hjælpe programmør i opbygge solide , vedligeholde applikationer. General Program Documentation

De første linjer af programmet bør omfatte "bemærkninger " linjer (se "Tilføjelse Bemærkninger "), som identificerer navnet på projektet , forfatteren af ​​programmet, oprettelsesdato og en beskrivelse af ansøgningen. Dette er standard dokumentation for alle programmeringssprog , da det hjælpemidler vedligeholdelse programmør i at identificere den oprindelige forfatter , som kan spare timers forskning tid.
Naming Variables
p Det er meget vigtigt, at du følger et godt sæt navngivning for variabler , så du vil være i stand til at vide, hvad du kigger på , når du forsøger desperat at debug dit program. Må ikke indeholde tegnsætning eller mellemrum i dine variabelnavne , og ikke bruge Visual Basic reserverede ord som variabelnavne eller VB vil afmærke dem som et problem. Brug Camel Casing (undertiden kaldet Pascal Casing ) til at navngive dine variabler . Dette refererer til den praksis kapitalisere det første bogstav i hvert nyt ord i en variabel navn. Her er flere eksempler:

BankBalanceDecimal

CheckNumberInteger

TotalDepositsDecimal

meddelelse om, at det sidste ord i variabelnavnet betegner sin datatype. Dette er ikke påkrævet , men er meget nyttigt , når de forsøger at finde en flygtig programmering bug . Selvfølgelig er der er fleksibilitet i denne , da VB ikke håndhæver dine standarder. Hvis du beslutter, at din standard vil indeholde en understregning mellem hvert ord i et variabelnavn derefter holde med standarden . Det er vigtigt at forstå, at konsekvens i følge de etablerede programmering standarder er nøglen.
Navngivning Form Komponenter

Tildeling navne til at danne komponenter ( eller kontroller ) såsom knapper, etiketter og tekstbokse , bør også følge en standard. Forlader standard navnene " Button1 " og " Label1 " bør aldrig betragtes som en realistisk mulighed , da det vil gøre debugging en frustrerende opgave i bedste fald. Mens du kan vælge at følge samme navngivning standard som dine variabelnavne , der kan være forvirrende så at vælge en ændring af dette ville være acceptabelt, og potentielt nyttige. For eksempel , let at placere en understregning mellem hvert ord i en kontrolgruppe identificerer det som en kontrol . Her er flere eksempler på kontrol navne : Hej

Calculate_Button

Name_TextBox

Blue_Radiobutton

Denne lille forskel hurtigt adskiller en komponent navn fra et variabelnavn og kan hjælpe reducere forvirring, når vedligeholdelse , afprøvning og debugging .
eksekverbare Udtalelser

Hver eksekverbare linje skal være sin egen linje , medmindre det er for lang til at passe på én linje, og har at videreføres. I dette tilfælde bør du led den fortsatte linie én fane for læsbarheden. Må ikke kombinere flere eksekverbare udsagn på én linje. Selvom Visual Basic giver dette ved hjælp af et kolon (:) som separator , er det ikke godt programmering praksis, da den anden meddelelse nemt kan blive overset. Husk, læsbarhed og forståelighed er målet , snarere end at minimere antallet af linjer kode i dit program .
Bemærkninger Statements

A " Bemærkning " (eller " Kommentar " ) erklæring begynder med en apostrof (' ), og er en ikke- eksekverbar erklæring. Hver procedure bør indeholde en bemærkning erklæring som den første linje (eller linjer) forklarer kort, hvad proceduren gør. Selvom Visual Basic ændrer farven på bemærkninger til grøn , er det en god idé at indsætte en tom bemærkning som den første linje og en tom bemærkning som den sidste linje i anmærkningerne del af en procedure. Dette øger læsbarheden og reducerer opgaven adskille eksekverbar kode fra bemærkninger .