Her finder du nogle råd, du bør tage i betragtning, når du begynder at udvikle dine egne Excel VBA-løsninger. At følge disse retningslinjer er ikke noget universalmiddel til at holde dig ude af (programmerings)problemer, men at følge dem kan hjælpe dig med at undgå faldgruber, som andre er faldet over.
Deklarer alle variabler
Hvor praktisk er det: Begynd ganske enkelt at skrive din VBA-kode uden at skulle gennemgå den kedelige opgave med at erklære hver eneste variabel, du vil bruge. Selvom Excel giver dig mulighed for at bruge ikke-erklærede variabler, er det blot at bede om problemer.
Det første bud i VBA-programmering bør være dette:
Du skal erklære hver variabel.
Hvis du mangler selvdisciplin, skal du tilføje en "Option Explicit"-erklæring øverst på dine moduler. På den måde vil din kode ikke engang køre, hvis den indeholder en eller flere udeklarerede variabler. Ikke at erklære alle variabler har kun én fordel: Du sparer et par sekunder. Men at bruge ikke-erklærede variabler vil i sidste ende komme tilbage til at hjemsøge dig.
Forveksle ikke adgangskoder med sikkerhed
Bare beskyt VBA-projektet med adgangskode, og du er sikker, ikke? Forkert.
Brug af en VBA-adgangskode kan forhindre de fleste afslappede brugere i at se din kode. Men hvis nogen virkelig vil tjekke det, vil han finde ud af, hvordan man knækker adgangskoden.
Bundlinie? Hvis du absolut, positivt har brug for at holde din kode hemmelig, er Excel ikke det bedste valg til en udviklingsplatform.
Ryd op i din kode
Når din app fungerer til din tilfredshed, bør du rydde op i den. Kodehusholdningsopgaver omfatter følgende:
-
Sørg for, at hver variabel er erklæret.
-
Sørg for, at alle linjerne er indrykket korrekt, så kodestrukturen er tydelig.
-
Fjern eventuelle fejlfindingshjælpemidler, såsom MsgBox-sætninger af Debug.Print-sætninger.
-
Omdøb eventuelle dårligt navngivne variable. For eksempel, hvis du bruger variablen MyVariable, er der en ret god chance for, at du kan gøre variabelnavnet mere beskrivende. Du vil takke dig selv senere.
-
Dine moduler har sandsynligvis et par "test"-procedurer, som du skrev, mens du forsøgte at finde ud af noget. De har tjent deres formål, så slet dem.
-
Tilføj kommentarer, så du forstår, hvordan koden fungerer, når du ser den igen om seks måneder.
-
Sørg for, at alt er stavet korrekt - især tekst i brugerformularer og beskedbokse.
-
Tjek for overflødig kode. Hvis du har to eller flere procedurer, der har identiske kodeblokke, kan du overveje at oprette en ny procedure, som andre procedurer kan kalde.
Læg ikke alt i én procedure
Vil du lave et uforståeligt program? En effektiv måde at opnå det på er at lægge al din kode ind i en dejlig stor procedure. Hvis du nogensinde besøger dette program igen for at foretage ændringer, er du forpligtet til at lave fejl og introducere nogle fine fejl.
Kan du se problemet? Løsningen er modulær kode. Opdel dit program i mindre bidder, med hver chunk designet til at udføre en bestemt opgave. Når du har taget denne vane op, vil du opdage, at det er nemmere end nogensinde at skrive fejlfri kode.
Overvej anden software
Excel er et utroligt alsidigt program, men det er ikke egnet til alt. Når du er klar til at påtage dig et nyt projekt, skal du bruge lidt tid på at overveje alle dine muligheder. For at omskrive et gammelt ordsprog, "Når alt hvad du ved er Excel VBA, ligner alt en VBA-makro."
Antag ikke, at alle aktiverer makroer
Som du ved, giver Excel dig mulighed for at åbne en projektmappe med dens makroer deaktiveret. Faktisk er det næsten, som om designere af nyere versioner af Excel ønsker, at brugerne skal deaktivere makroer.
At aktivere makroer, når du åbner en projektmappe fra en ukendt kilde, er selvfølgelig ikke en god idé. Så du skal kende dine brugere. I nogle virksomhedsmiljøer er alle Microsoft Office-makroer deaktiveret, og brugeren har ikke noget valg i sagen.
En ting at overveje er at tilføje en digital signatur til de projektmapper, som du distribuerer til andre. På den måde kan brugeren være sikker på, at projektmapperne faktisk kommer fra dig, og at de ikke er blevet ændret. Se hjælpesystemet for at få flere oplysninger om digitale signaturer.
Få for vane at eksperimentere
Opsætning af simple eksperimenter er næsten altid meget mere effektivt end at inkorporere en ny idé i din eksisterende kode uden at forstå, hvad disse eksperimenter bringer.
Gå ikke ud fra, at din kode vil fungere med andre Excel-versioner
I øjeblikket er mindst fem versioner af Excel almindeligt anvendt rundt om i verden. Når du opretter en Excel-app, har du absolut ingen garanti for, at den vil fungere fejlfrit i ældre versioner eller i nyere versioner. I nogle tilfælde vil uforenelighederne være indlysende. Men du vil også opdage, at ting, der burde fungere med en tidligere version, ikke virker.
Excel inkluderer en praktisk kompatibilitetskontrol (vælg Filer → Info → Tjek for problemer → Kontroller kompatibilitet), men den kontrollerer kun projektmappen og ignorerer VBA-koden. Den eneste måde at være sikker på, at din applikation fungerer med andre versioner end den, du oprettede den med, er at teste den i disse versioner.
Husk dine brugere
Hvis du udvikler apps til andre, er dit job sværere, fordi du ikke kan lave de samme typer antagelser, som du gør, når du udvikler for dig selv.
For eksempel kan du være mere slap med fejlhåndtering, hvis du er den eneste bruger. Hvis der dukker en fejl op, har du en ret god idé om, hvor du skal lede, så du kan rette den. Hvis en anden bruger din app, og den samme fejl vises, vil han eller hun være uheldig. Og når du arbejder med din egen applikation, kan du normalt klare dig uden instruktioner.
Du skal forstå færdighedsniveauet hos dem, der skal bruge dine projektmapper, og forsøge at forudse problemer, som de måtte have. Prøv at forestille dig dig selv som en ny bruger af din applikation, og identificer alle områder, der kan forårsage forvirring eller problemer.
Glem ikke sikkerhedskopier
Intet er mere nedslående end et harddisknedbrud uden en backup. Hvis du arbejder på et vigtigt projekt, så spørg dig selv et simpelt spørgsmål: "Hvis min computer dør i aften, hvad har jeg så mistet?" Hvis dit svar er mere end et par timers arbejde, skal du se nærmere på din procedure for sikkerhedskopiering af data. Du har en procedure for sikkerhedskopiering af data, ikke?