Stille inn Visual Studio Compiler-alternativer, del 1

Dette er en serie om innstilling av kompilatoralternativer for Visual Studio VB.NET-prosjekter, versjoner 2005-2010. Kompilatoralternativer er innstillinger på prosjektnivå som bestemmer hvordan kompilatoren oppfører seg når den kompilerer koden din. Du viser og angir kompilatoralternativer i Compile-fanen til prosjektegenskapsarket ( figur A ).

Figur A

Jeg har ikke tenkt å komme inn på en filosofisk diskusjon om hvorvidt folk skal skrive kode i VB.NET. Realiteten er at noen gjør det, og de trenger denne informasjonen. Målet mitt her er å gi informasjon til de som har valgt å (eller må) bruke VB.NET.

Dette er en ganske høyt nivå diskusjon av kompilatoralternativer - som jeg mener det er fra synspunktet til programmereren som ser på alternativene i VS IDE og lurer på dem. Alternativene du ser på IDE er et forenklet bilde av de 100+ alternativene som faktisk er tilgjengelige for kompilatoren. Det er min antagelse at de som leser denne artikkelen er mer interessert i alternativene som er tilgjengelige via IDE, enn å gå under overflaten.

I denne serien vil jeg forklare hvert av alternativene som presenteres i IDE, som gjeldende for alle konfigurasjoner, og anbefale hvordan du angir dem. Figur B viser en liste over alternativene fra versjon 2010.

Figur B

La meg først liste over alternativene sammen med standardverdiene (dvs. som installert):

Alternativ Misligholde
Alternativ eksplisitt
Alternativ strengt Av
Alternativ sammenlign Binary
Alternativ infer (2010)
Implisitt konvertering Ingen
Sen binding; samtale kan mislykkes ved kjøretid Ingen
Implisitt type; objekt antatt Ingen
Bruk av variabel før tildeling Advarsel
Funksjon / operatør uten returverdi Advarsel
Ubrukt lokal variabel Advarsel
Forekomstvariabel får tilgang til delt medlem Advarsel
Rekursiv tilgang til operatør eller eiendom Advarsel
Dupliser eller overlapp fangstblokker Advarsel

I denne første delen, del 1, vil jeg diskutere det første alternativet, alternativ eksplisitt.

Hva det betyr

Alternativ eksplisitt avgjør om VB.NET krever eksplisitte variabeldeklarasjoner. Visual Basic er et gammelt språk med mange tilgivende regler, så med mindre du forteller det annet, vil det la deg bruke en variabel uten å erklære den, slik jeg har gjort her:

 Privat funksjon GetPostalCode () 
 UndeclaredVariable = "22205-7509" 
 Return UndeclaredVariable 
 Sluttfunksjon 

Når ble mysterievariabelen min opprettet? Første gang jeg brukte den. Jeg trengte ikke å erklære det i det hele tatt. Slik oppfører VB.NET seg med alternativ eksplisitt satt til Av.

Å stille alternativ eksplisitt til På (standard) tvinger deg til å deklarere alle variabler før du bruker dem, som her:

 Privat funksjon GetPostalCode () 
 Dim DeclaredVariable 
 DeclaredVariable = "22205-7509" 
 Return DeclaredVariable 
 Sluttfunksjon 

Nå har ikke kompilatoren lov til å lage variabelen første gang jeg bruker den. Jeg må erklære det først.

Hvorfor det er viktig

Hovedfaren for å hoppe over variabelerklæring er utilsiktet variasjon . Med alternativ eksplisitt av ser linjer du skriver som oppretter variabler nøyaktig ut som linjer du skriver som bruker dem. Dette betyr at du enkelt kan opprette variabler bare ved å stavefeil variabler du hadde tenkt å bruke. Siden stavefeil er utilsiktet, fører dette vanligvis til feil å finne feil. Denne faren er spesielt utbredt i lange rutiner og store programmer. Se for deg dette veldig fortenkte scenariet:

 Privat funksjon GetFormattedPostalCode () 
 MysteryVariable = "22205" 
 Separator = "-" 
 ThirdPart = "7509" 
 Hvis ThirdPart.Length> 0 Then 
 MysteryVeriable = MysteryVariable & Separator & ThirdPart 
 Slutt om 
 Return MysteryVariable 
 Sluttfunksjon 

Den rutinen vil alltid returnere 22205, fordi den utilsiktet oppretter en ny variabel i If..Then-leddet - en variabel som aldri blir brukt. Å slå alternativ eksplisitt på ganske enkelt vil ikke la det skje.

Hva jeg skal gjøre med det

Hvis det er ditt prosjekt, og du har et valg, bør du la Option Explicit være satt til På. Det er egentlig ingen grunn til å slå den av. Og hvis du slår det av, vil du senke skjoldene som beskytter programmet ditt, uten noen fordel for deg bortsett fra den tvilsomme fordelen ved å skrive mindre - en falsk fordel, siden du vil måtte gjøre mye mer å skrive i løpet av å finne, fikse, og prøve å forklare feilene som følger av det.

Hva om det ikke er ditt prosjekt? Hvis du har arvet en annens prosjekt hvis Option Explicit er satt til Off, slå på det og se om prosjektet til og med kompilerer - det vil ikke hvis ikke en variabel mangler en deklarasjon. I så fall må du gå gjennom alle feilene som lander på ikke-angitte variabler og erklære dem. Men vær forsiktig og fikse dem én om gangen - du kan finne mer enn en utilsiktet opprettet variabel, og hvis du gjør det, må du sørge for at du forstår det tilsiktede resultatet, og at endringen får deg dit. Det er kanskje ikke greit.

Hvis prosjektet samles, bør du være god å gå.

Konklusjon

Option Explicit har vært med Visual Basic i sine forskjellige former i lang tid. Det er fordi språket i seg selv ikke krever variable erklæringer. Men farene ved å ikke deklarere variabler oppveier noen antatte fordeler. Sett alternativ eksplisitt til På i alle VB.NET-prosjektene dine.

© Copyright 2021 | pepebotifarra.com