Introduktion till Visual Basic

Programmeringsspråket Microsoft® Visual Basic® är ett programmeringsspråk på hög nivå för Microsoft .NET Framework. Även om det är utformat för att vara ett lättillgängligt och lättlärt språk, är det också tillräckligt kraftfullt för att tillgodose behoven hos erfarna programmerare. Programmeringsspråket Visual Basic har en syntax som liknar engelska, vilket ökar tydligheten och läsbarheten för Visual Basic-kod. När det är möjligt används meningsfulla ord eller fraser i stället för förkortningar, förkortningar eller specialtecken. Onödig eller onödig syntax tillåts vanligtvis men krävs inte.

Programmeringsspråket Visual Basic kan antingen vara ett starkt skrivet eller ett löst skrivet språk. Lös skriva defers mycket av bördan av typkontroll tills ett program redan körs. Detta omfattar inte bara typkontroll av konverteringar utan även av metodanrop, vilket innebär att bindningen av ett metodanrop kan skjutas upp till körning. Detta är användbart när du skapar prototyper eller andra program där utvecklingshastigheten är viktigare än körningshastigheten. Programmeringsspråket Visual Basic innehåller också starkt typinskrivna semantik som utför all typkontroll vid kompileringstid och tillåter inte körningsbindning av metodanrop. Detta garanterar maximal prestanda och hjälper till att säkerställa att typkonverteringar är korrekta. Detta är användbart när du skapar produktionsprogram där körnings- och körningskorrigeringen är viktig.

I det här dokumentet beskrivs språket Visual Basic. Det är tänkt att vara en fullständig språkbeskrivning snarare än en språkguide eller en användares referenshandbok.

Grammatik notation

Den här specifikationen beskriver två grammatiker: en lexikal grammatik och en syntaktisk grammatik. Den lexikala grammatiken definierar hur tecken kan kombineras för att bilda token. den syntaktiska grammatiken definierar hur token kan kombineras för att bilda Visual Basic-program. Det finns också flera sekundära grammatiker som används för förbearbetningsåtgärder som villkorlig kompilering.

Grammatikerna i den här specifikationen är skrivna i ANTLR-format – se http://www.antlr.org/.

Skiftläget är oviktigt i Visual Basic-program. För enkelhetens skull kommer alla terminaler att ges i standardhöljet, men alla höljen matchar dem. Terminaler som är utskrivbara element i ASCII-teckenuppsättningen representeras av motsvarande ASCII-tecken. Visual Basic är också skiftlägeskänsligt vid matchning av terminaler, vilket gör att Unicode-tecken med full bredd kan matcha deras unicode-motsvarigheter med halv bredd, men bara på heltoken. En token matchar inte om den innehåller blandade tecken med halv bredd och full bredd.

Radbrytningar och indrag kan läggas till för läsbarhet och ingår inte i produktionen.

Kompatibilitet

En viktig funktion i ett programmeringsspråk är kompatibilitet mellan olika versioner av språket. Om en nyare version av ett språk inte accepterar samma kod som en tidigare version av språket, eller tolkar den annorlunda än den tidigare versionen, kan en börda läggas på en programmerare när han uppgraderar sin kod från en version av språket till en annan. Därför måste kompatibiliteten mellan versioner bevaras, förutom när fördelen för språkkonsumenterna är av klar och överväldigande karaktär.

Följande princip styr ändringar av Visual Basic-språket mellan versioner. Termen språk, när det används i den här kontexten, refererar endast till syntaktiska och semantiska aspekter av själva Visual Basic-språket och innehåller inte några .NET Framework-klasser som ingår som en del av Microsoft.VisualBasic namnområdet (och undernamnsrymder). Alla klasser i .NET Framework omfattas av en separat versions- och kompatibilitetsprincip utanför omfånget för det här dokumentet.

Typer av kompatibilitetsbrytningar

I en idealisk värld skulle kompatibiliteten vara 100% mellan den befintliga versionen av Visual Basic och alla framtida versioner av Visual Basic. Det kan dock finnas situationer där behovet av en kompatibilitetsbrytning kan uppväga de kostnader som det kan medföra för programmerare. Sådana situationer är:

• Nya varningar. Att införa en ny varning är i sig inte en kompatibilitetsbrytning. Men eftersom många utvecklare kompilerar med "behandla varningar som fel" aktiverade, måste extra försiktighet iakttas när varningar införs.

• Nya nyckelord. Det kan vara nödvändigt att introducera nya nyckelord när du introducerar nya språkfunktioner. Rimliga ansträngningar kommer att göras för att välja nyckelord som minimerar risken för kollision med användarnas identifierare och att använda befintliga nyckelord där det är meningsfullt. Hjälp kommer att ges för att uppgradera projekt från tidigare versioner och undvika nya nyckelord.

• Kompilatorbuggar. När kompilatorns beteende strider mot ett dokumenterat beteende i språkspecifikationen kan det vara nödvändigt att åtgärda kompilatorns beteende för att matcha det dokumenterade beteendet.

• Specifikationsfel. När kompilatorn överensstämmer med språkspecifikationen men språkspecifikationen är helt klart felaktig kan det vara nödvändigt att ändra språkspecifikationen och kompilatorns beteende. Frasen "klart fel" innebär att det dokumenterade beteendet strider mot vad en tydlig och entydig majoritet av användarna skulle förvänta sig och ger mycket oönskat beteende för användare.

• Specifikation tvetydighet. När språkspecifikationen ska ange vad som händer i en viss situation men inte gör det, och kompilatorn hanterar situationen på ett sätt som antingen är inkonsekvent eller helt fel (med samma definition från föregående punkt), kan det vara nödvändigt att förtydliga specifikationen och korrigera kompilatorns beteende. Med andra ord, när specifikationen omfattar fall a, b, d och e, men utelämnar något omnämnande av vad som händer i fall c, och kompilatorn beter sig felaktigt i fall c, kan det vara nödvändigt att dokumentera vad som händer om c och ändra kompilatorns beteende att matcha. (Observera att om specifikationen var tvetydig om vad som händer i en situation och kompilatorn beter sig på ett sätt som inte är helt fel blir kompilatorns beteende de facto-specifikationen.)

• Göra körningsfel till kompileringsfel. I en situation där koden är 100% garanterat misslyckas vid körning (dvs. användarkoden har en entydig bugg i den), kan det vara önskvärt att lägga till ett kompileringsfel som fångar situationen.

• Utelämnande av specifikation. När språkspecifikationen inte uttryckligen tillåter eller inte tillåter en viss situation och kompilatorn hanterar situationen på ett sätt som är oönskat (om kompilatorns beteende var uppenbart fel, skulle det vara en specifikationsfel, inte en specifikationsförsummelse), kan det vara nödvändigt att klargöra specifikationen och ändra kompilatorns beteende. Förutom den vanliga konsekvensanalysen begränsas ändringar av detta slag ytterligare till fall där effekten av ändringen anses vara extremt minimal och fördelen för utvecklare är mycket hög.

• Nya funktioner. I allmänhet bör introduktionen av nya funktioner inte ändra befintliga delar av språkspecifikationen eller kompilatorns befintliga beteende. I den situation där införandet av en ny funktion kräver att den befintliga språkspecifikationen ändras är en sådan kompatibilitetsbrytning rimlig endast om effekten skulle vara extremt minimal och fördelen med funktionen är hög.

• Säkerhet. I extraordinära situationer kan säkerhetsproblem kräva en kompatibilitetsbrytning, till exempel att ta bort eller ändra en funktion som i sig är osäker och utgör en tydlig säkerhetsrisk för användarna.

Följande situationer är inte godtagbara skäl för att införa kompatibilitetsbrytningar:

• Oönskat eller beklagligt beteende. Språkdesign eller kompilatorbeteende som är rimligt men som anses oönskat eller beklagligt i efterhand är inte en motivering för att bryta bakåtkompatibiliteten. Språkutfasningsprocessen, som beskrivs nedan, måste användas i stället.

• Något mer. Annars förblir kompilatorbeteendet bakåtkompatibelt.

Effektkriterier

När du överväger om en kompatibilitetsbrytning kan vara acceptabel används flera kriterier för att avgöra vilken effekt ändringen kan ha. Ju större påverkan, desto högre är fältet för att acceptera kompatibilitetsbrytningarna.

Kriterierna är:

• Vad är omfånget för ändringen? Med andra ord, hur många program kommer sannolikt att påverkas? Hur många användare kommer sannolikt att påverkas? Hur vanligt är det att skriva kod som påverkas av ändringen?

• Finns det några lösningar för att få samma beteende före ändringen?

• Hur uppenbar är förändringen? Kommer användarna att få omedelbar feedback om att något har ändrats, eller kommer deras program bara att köras annorlunda?

• Kan ändringen åtgärdas på ett rimligt sätt under uppgraderingen? Är det möjligt att skriva ett verktyg som kan hitta den situation där ändringen sker med perfekt noggrannhet och ändra koden för att kringgå ändringen?

• Vad är communityns feedback om ändringen?

Språkutfasning

Med tiden kan delar av språket eller kompilatorn bli inaktuella. Som tidigare nämnts är det inte acceptabelt att bryta kompatibiliteten för att ta bort sådana inaktuella funktioner. I stället måste följande steg följas:

1. Med tanke på en funktion som finns i version A av Visual Studio måste feedback begäras från användarcommunityn om utfasning av funktionen och fullständigt meddelande som ges innan något slutligt utfasningsbeslut fattas. Utfasningsprocessen kan ångras eller överges när som helst baserat på feedback från användarcommunityn.

2. fullständig version (dvs. inte en punktversion) B i Visual Studio måste släppas med kompilatorvarningar som varnar för inaktuell användning. Varningarna måste vara aktiverade som standard och kan stängas av. Utfasningarna måste vara tydligt dokumenterade i produktdokumentationen och på webben.

3. En fullständig version C av Visual Studio måste släppas med kompilatorvarningar som inte kan stängas av.

4. En fullständig version D av Visual Studio måste därefter släppas med de inaktuella kompilatorvarningarna konverterade till kompilatorfel. Lanseringen av D måste ske efter slutet av mainstream-supportfasen (5 år från och med den här skriften) av version A.

5. Slutligen kan en version E av Visual Studio släppas som tar bort kompilatorfelen.

Ändringar som inte kan hanteras inom det här utfasningsramverket tillåts inte.