Her finner du noen råd du bør ta hensyn til når du begynner å utvikle dine egne Excel VBA-løsninger. Å følge disse retningslinjene er ingen universalmiddel for å holde deg unna (programmerings)problemer, men å følge dem kan hjelpe deg med å unngå fallgruver som andre har snublet over.
Deklarer alle variabler
Hvor praktisk det er: Bare begynn å skrive inn VBA-koden din uten å måtte gå gjennom den kjedelige oppgaven med å deklarere hver eneste variabel du vil bruke. Selv om Excel lar deg bruke ikke-deklarerte variabler, er det ganske enkelt å be om problemer.
Det første budet til VBA-programmering bør være dette:
Du skal deklarere hver variabel.
Hvis du mangler selvdisiplin, legg til en "Alternativ Eksplisitt"-erklæring øverst i modulene dine. På den måten vil koden din ikke engang kjøre hvis den inneholder en eller flere uerklærte variabler. Å ikke deklarere alle variabler har bare én fordel: Du sparer noen få sekunder. Men å bruke uerklærte variabler vil etter hvert komme tilbake til å hjemsøke deg.
Ikke forveksle passord med sikkerhet
Bare passordbeskytt VBA-prosjektet, så er du trygg, ikke sant? Feil.
Å bruke et VBA-passord kan hindre de fleste tilfeldige brukere fra å se koden din. Men hvis noen virkelig vil sjekke det, vil han finne ut hvordan man knekker passordet.
Bunnlinjen? Hvis du absolutt trenger å holde koden hemmelig, er ikke Excel det beste valget for en utviklingsplattform.
Rydd opp i koden din
Etter at appen din fungerer tilfredsstillende, bør du rydde opp i den. Kodehusholdsoppgaver inkluderer følgende:
-
Sørg for at hver variabel er deklarert.
-
Sørg for at alle linjene er riktig rykket inn slik at kodestrukturen er tydelig.
-
Fjern eventuelle feilsøkingshjelpemidler, for eksempel MsgBox-setninger av Debug.Print-setninger.
-
Gi nytt navn til variabler med dårlig navn. For eksempel, hvis du bruker variabelen MyVariable, er det en ganske god sjanse for at du kan gjøre variabelnavnet mer beskrivende. Du vil takke deg selv senere.
-
Modulene dine har sannsynligvis noen få "test"-prosedyrer som du skrev mens du prøvde å finne ut av noe. De har tjent sin hensikt, så slett dem.
-
Legg til kommentarer slik at du forstår hvordan koden fungerer når du ser den på nytt om seks måneder.
-
Sørg for at alt er stavet riktig - spesielt tekst i brukerskjemaer og meldingsbokser.
-
Se etter overflødig kode. Hvis du har to eller flere prosedyrer som har identiske kodeblokker, bør du vurdere å opprette en ny prosedyre som andre prosedyrer kan kalle.
Ikke legg alt i én prosedyre
Vil du lage et uforståelig program? En effektiv måte å oppnå det på er å legge all koden din i en stor prosedyre. Hvis du noen gang besøker dette programmet igjen for å gjøre endringer, er du nødt til å gjøre feil og introdusere noen fine feil.
Ser du problemet? Løsningen er modulær kode. Del opp programmet i mindre biter, med hver del designet for å utføre en spesifikk oppgave. Etter at du har tatt opp denne vanen, vil du oppdage at det er enklere enn noen gang å skrive feilfri kode.
Vurder annen programvare
Excel er et utrolig allsidig program, men det passer ikke til alt. Når du er klar til å gjennomføre et nytt prosjekt, ta deg tid til å vurdere alle alternativene dine. For å parafrasere et gammelt ordtak, "Når alt du vet er Excel VBA, ser alt ut som en VBA-makro."
Ikke anta at alle aktiverer makroer
Som du vet, lar Excel deg åpne en arbeidsbok med makroene deaktivert. Faktisk er det nesten som om designere av nyere versjoner av Excel vil at brukere skal deaktivere makroer.
Å aktivere makroer når du åpner en arbeidsbok fra en ukjent kilde er selvfølgelig ikke en god idé. Så du må kjenne brukerne dine. I noen bedriftsmiljøer er alle Microsoft Office-makroer deaktivert, og brukeren har ikke noe valg i saken.
En ting å vurdere er å legge til en digital signatur i arbeidsbøkene som du distribuerer til andre. På den måten kan brukeren være trygg på at arbeidsbøkene faktisk kommer fra deg og at de ikke har blitt endret. Se hjelpesystemet for mer informasjon om digitale signaturer.
Gjør det for vane å eksperimentere
Å sette opp enkle eksperimenter er nesten alltid mye mer effektivt enn å inkorporere en ny idé i den eksisterende koden din uten å forstå hva disse eksperimentene gir.
Ikke anta at koden din vil fungere med andre Excel-versjoner
For øyeblikket brukes minst fem versjoner av Excel over hele verden. Når du oppretter en Excel-app, har du absolutt ingen garanti for at den vil fungere feilfritt i eldre versjoner eller i nyere versjoner. I noen tilfeller vil inkompatibilitetene være åpenbare. Men du vil også oppdage at ting som burde fungere med en tidligere versjon, ikke fungerer.
Excel inkluderer en hendig kompatibilitetskontroller (velg Fil → Info → Se etter problemer → Sjekk kompatibilitet), men den sjekker bare arbeidsboken og ignorerer VBA-koden. Den eneste måten å være sikker på at applikasjonen din fungerer med andre versjoner enn den du opprettet den med, er å teste den i disse versjonene.
Ha brukerne dine i tankene
Hvis du utvikler apper for andre, er jobben din vanskeligere fordi du ikke kan gjøre de samme typene forutsetninger som du gjør når du utvikler for deg selv.
Du kan for eksempel være mer slapp med feilhåndtering hvis du er den eneste brukeren. Hvis det dukker opp en feil, har du en ganske god idé om hvor du skal lete slik at du kan fikse den. Hvis noen andre bruker appen din og den samme feilen vises, vil han eller hun være uheldig. Og når du jobber med din egen applikasjon, kan du vanligvis klare deg uten instruksjoner.
Du må forstå ferdighetsnivået til de som skal bruke arbeidsbøkene dine og prøve å forutse problemer de kan ha. Prøv å forestille deg deg selv som en ny bruker av applikasjonen din, og identifiser alle områder som kan forårsake forvirring eller problemer.
Ikke glem sikkerhetskopier
Ingenting er mer nedslående enn en harddiskkrasj uten en sikkerhetskopi. Hvis du jobber med et viktig prosjekt, spør deg selv et enkelt spørsmål: "Hvis datamaskinen min dør i kveld, hva vil jeg ha mistet?" Hvis svaret ditt er mer enn noen få timers arbeid, må du se nærmere på prosedyren for sikkerhetskopiering av data. Du har en prosedyre for sikkerhetskopiering av data, ikke sant?