Hver programmeringsspråk har noen sett av standarder som er ment å bringe en grad av konsistens til bygging av et program. Disse standardene inkluderer slike ting som navngiving , kapitalisering og staving av variabelnavn , innrykk standarder og dokumentasjon standarder . Mens en rookie programmerer kan vurdere disse standardene for å være en tidkrevende bry , vet erfaren programmerer at disse standardene øker forståelighet og redusere vedlikehold tid . Visual Basic har sitt eget sett med programmering standarder for å hjelpe programmereren i å bygge solide , vedlikeholde applikasjoner. Generell Program Dokumentasjon
De første linjene av programmet skal inneholde "Merknader" linjer ( se " Legge Merknader ") som identifiserer navnet på prosjektet , forfatteren av programmet , dato opprettet og en beskrivelse av programmet . Dette er standard dokumentasjon for alle programmeringsspråk siden det hjelpemidler vedlikehold programmerer i å identifisere den opprinnelige forfatteren , som kan spare timer med forskning tid .
Naming Variabler
p Det er svært viktig at du følger et godt sett med navnekonvensjonene for variabler slik at du vil være i stand til å vite hva du ser på når du prøver desperat å feilsøke programmet . Ikke ta med tegnsetting eller mellomrom i dine variabelnavn , og ikke bruke Visual Basic reserverte ord som variabelnavn eller VB vil flagge dem som et problem . Bruk Camel Casing (noen ganger kalt Pascal kammer) å navngi variablene . Dette refererer til praksisen med å utnytte den første bokstaven i hvert nytt ord i en variabel navn . Her er flere eksempler:
BankBalanceDecimal
CheckNumberInteger
TotalDepositsDecimal
merke til at det siste ordet i variabelen navnet betegner sin datatype. Dette er ikke nødvendig , men er svært nyttig når du prøver å finne en unnvikende programmering bug . Selvfølgelig det er fleksibilitet i dette, siden VB ikke håndheve dine standarder. Hvis du bestemmer deg for at standarden vil omfatte en understrek mellom hvert ord i en variabel navn deretter pinne med standarden. Det er viktig å forstå at konsistens i følge etablerte standarder programmering er nøkkelen .
Naming Form Komponenter
Tilordne navn for å danne komponenter ( eller kontroller ) som for eksempel knapper, etiketter og tekstbokser , bør også følge en standard . Leaving standard navnene " Button1 " og " Label1 " bør aldri betraktes som en levedyktig alternativ som det vil gjøre debugging en frustrerende ork i beste fall. Mens du kan velge å følge den samme navngiving standard som dine variabelnavn som kan være forvirrende så velge en modifikasjon av dette ville være akseptabelt og potensielt nyttig . For eksempel plassere en understrek mellom hvert ord i en kontroll navn lett identifiserer den som en kontroll . Her er flere eksempler på kontroll navn : en
Calculate_Button
Name_TextBox
Blue_Radiobutton
liten forskjell raskt skiller en komponent navn fra en variabel navn og kan hjelpe redusere forvirring når vedlikehold , testing og debugging .
kjørbare Uttalelser
Hver kjørbar linje skal være sin egen linje med mindre den er for lang til å passe på én linje , og har til videreføres. I dette tilfellet bør du rykke inn den fortsatte linjen én fane for lesbarhet . Ikke kombinere flere kjørbare utsagn på én linje. Selv om Visual Basic gjør dette ved hjelp av et kolon ( :) som en separator , er det ikke god programmering praksis , siden den andre setningen kan lett bli oversett . Husk, lesbarhet og forståelighet målet, heller enn å redusere antall linjer med kode i programmet.
Merknader Uttalelser
A " Kommentar " (eller " Comment ") setningen begynner med en apostrof (' ) og er en ikke-kjørbare setningen. Hver prosedyre bør inneholde en bemerkning uttalelse som første linje ( eller linjer) forklarer kort hva prosedyren gjør. Selv om Visual Basic endrer fargen på bemerkninger til grønt , er det lurt å inkludere en blank bemerkning som første linje og en blank bemerkning som den siste linjen i kommentarfeltet av en prosedyre . Dette øker lesbarheten og reduserer oppgaven med å skille kjørbar kode fra bemerkninger.
