Bevezetés a Visual Basic használatába

A Microsoft® Visual Basic® programozási nyelv a Microsoft .NET-keretrendszer magas szintű programozási nyelve. Bár úgy tervezték, hogy egy megközelíthető és könnyen tanulható nyelv, ez is elég erős, hogy kielégítse a tapasztalt programozók igényeit. A Visual Basic programozási nyelv az angolhoz hasonló szintaxissal rendelkezik, amely elősegíti a Visual Basic-kód érthetőségét és olvashatóságát. Ahol csak lehetséges, a rövidítések, mozaikszavak vagy speciális karakterek helyett értelmes szavakat vagy kifejezéseket használnak. A felesleges vagy szükségtelen szintaxis általánosan engedélyezett, de nem kötelező.

A Visual Basic programozási nyelv lehet erősen beírt vagy lazán beírt nyelv. Laza gépelés defers nagy terhet a típus-ellenőrzés, amíg egy program már fut. Ez nem csak a konverziók típusellenőrzését, hanem a metódushívások típusellenőrzését is magában foglalja, ami azt jelenti, hogy a metódushívás kötése a futtatásig késleltethető. Ez akkor hasznos, ha prototípusokat vagy más programokat készít, amelyekben a fejlesztés sebessége fontosabb, mint a végrehajtási sebesség. A Visual Basic programozási nyelv emellett erősen gépelt szemantikát is biztosít, amely fordítási időben végez minden típusellenőrzést, és letiltja a metódushívások futásidejű kötését. Ez garantálja a maximális teljesítményt, és segít biztosítani, hogy a típuskonverziók helyesek legyenek. Ez akkor hasznos, ha éles alkalmazásokat készít, amelyekben fontos a végrehajtás sebessége és a végrehajtás helyessége.

Ez a dokumentum a Visual Basic nyelvét ismerteti. Ez egy teljes nyelvi leírás, nem pedig egy nyelvi oktatóanyag vagy egy felhasználó referencia-kézikönyve.

Nyelvtani jelölés

Ez a specifikáció két nyelvtant ír le: egy lexikális és egy szintaktikai nyelvtant. A lexikális nyelvhelyesség határozza meg, hogyan lehet a karaktereket tokenekké egyesíteni; a szintaktikai nyelvhelyesség határozza meg, hogyan kombinálhatók a jogkivonatok a Visual Basic-programok létrehozásához. Az előfeldolgozási műveletekhez, például a feltételes fordításhoz is számos másodlagos nyelvtan használható.

Az ebben a specifikációban szereplő nyelvtanok ANTLR formátumban vannak megírva – lásd http://www.antlr.org/.

A kis- és nagybetűk nem lényegesek a Visual Basic-programokban. Az egyszerűség kedvéért az összes terminál szabványos burkolatban lesz megadva, de minden burkolat megegyezik velük. Az ASCII-karakterkészlet nyomtatható elemeit a hozzájuk tartozó ASCII-karakterek jelölik. A Visual Basic szintén érzéketlen a terminálok megfelelő szélessége esetén, így a teljes szélességű Unicode-karakterek megfelelnek a félszélességű Unicode-megfelelőiknek, de csak teljes jogkivonat alapján. A jogkivonat nem egyezik, ha vegyes félszélességű és teljes szélességű karaktereket tartalmaz.

A sortörések és behúzások hozzáadhatók az olvashatóság érdekében, és nem részei az éles környezetnek.

Kompatibilitás

A programozási nyelv fontos funkciója a nyelv különböző verziói közötti kompatibilitás. Ha egy nyelv újabb verziója nem fogadja el ugyanazt a kódot, mint a nyelv egy korábbi verziója, vagy az előző verziótól eltérően értelmezi azt, akkor a programozót terhelheti, ha a kódot a nyelv egyik verziójáról a másikra frissíti. Ezért a verziók közötti kompatibilitást meg kell őrizni, kivéve, ha a nyelvi felhasználók számára nyújtott előny egyértelmű és elsöprő természetű.

Az alábbi szabályzat szabályozza a Visual Basic nyelv módosításait a verziók között. Az ebben a kontextusban használt nyelv csak a Visual Basic nyelv szintaktikai és szemantikai aspektusaira vonatkozik, és nem tartalmaz .NET-keretrendszerosztályokat a Microsoft.VisualBasic névtér (és alnévterek) részeként. A .NET-keretrendszer minden osztályára külön verziószámozási és kompatibilitási szabályzat vonatkozik, amely a dokumentum hatókörén kívül esik.

Kompatibilitási törések típusai

Ideális világban a kompatibilitás 100% lenne a Visual Basic meglévő és a Visual Basic jövőbeli verziói között. Lehetnek azonban olyan helyzetek, amikor a kompatibilitási szünet szükségessége meghaladja a programozókra háruló költségeket. Ilyen helyzetek a következők:

• Új figyelmeztetések. Az új figyelmeztetés bevezetése önmagában nem kompatibilitási törés. Mivel azonban sok fejlesztő fordítja le a "figyelmeztetések hibaként való kezelése" funkciót, különös figyelmet kell fordítani a figyelmeztetések bevezetésekor.

• Új kulcsszavak. Új kulcsszavak bevezetésére lehet szükség az új nyelvi funkciók bevezetésekor. Ésszerű erőfeszítéseket teszünk annak érdekében, hogy olyan kulcsszavakat választsunk, amelyek minimálisra csökkentik a felhasználók azonosítóival való ütközés lehetőségét, és hogy a meglévő kulcsszavakat használjuk, ahol van értelme. Segítséget nyújtunk a korábbi verziók projektjeinek frissítéséhez és az új kulcsszavak megkerüléséhez.

• Fordítóhibák. Ha a fordító viselkedése ellentétes a nyelvi specifikációban szereplő dokumentált viselkedéssel, szükség lehet a fordító viselkedésének a dokumentált viselkedésnek megfelelő rögzítésére.

• Specifikációs hiba. Ha a fordító összhangban van a nyelvi specifikációval, de a nyelvi specifikáció egyértelműen helytelen, szükség lehet a nyelvi specifikáció és a fordító viselkedésének módosítására. A "egyértelműen helytelen" kifejezés azt jelenti, hogy a dokumentált viselkedés ellentétes azzal, amit a felhasználók egyértelmű és egyértelmű többsége elvárna, és rendkívül nemkívánatos viselkedést eredményezne a felhasználók számára.

• A specifikáció kétértelműsége. Ha a nyelvi specifikációnak meg kell határoznia, hogy mi történik egy adott helyzetben, de nem, és a fordító úgy kezeli a helyzetet, hogy az inkonzisztens vagy egyértelműen helytelen (az előző ponttól származó definíciót használva), szükség lehet a specifikáció pontosítására és a fordító viselkedésének javítására. Más szóval, ha a specifikáció az a, b, d és e esetekre vonatkozik, de nem említi meg, hogy mi történik a c esetben, és a fordító helytelenül viselkedik a c esetben, szükség lehet arra, hogy dokumentálja, mi történik a c esetben, és módosítsa a fordító viselkedését az egyezésre. (Vegye figyelembe, hogy ha a specifikáció nem egyértelmű, hogy mi történik egy adott helyzetben, és a fordító úgy viselkedik, hogy nem egyértelműen helytelen, akkor a fordító viselkedése de facto specifikációvá válik.)

• Futásidejű hibák fordítási idejű hibákká alakítása. Olyan esetben, amikor a kód 100% futásidőben garantáltan sikertelen lesz (azaz a felhasználói kódban egyértelmű hiba van), célszerű lehet olyan fordítási időt érintő hibát hozzáadni, amely elkapja a helyzetet.

• Specifikáció kihagyása. Ha a nyelvi specifikáció nem engedélyezi vagy tiltja le konkrétan egy adott helyzetet, és a fordító nem kívánatos módon kezeli a helyzetet (ha a fordító viselkedése egyértelműen helytelen volt, specifikációhiba lenne, nem specifikáció kihagyása), szükség lehet a specifikáció tisztázására és a fordító viselkedésének módosítására. A szokásos hatáselemzés mellett az ilyen jellegű változások tovább korlátozódnak azokra az esetekre, amikor a változás hatása rendkívül minimálisnak tekinthető, és a fejlesztőknek nyújtott előnyök nagyon magasak.

• Új funkciók. Az új funkciók bevezetése általában nem módosíthatja a nyelvi specifikáció meglévő részeit vagy a fordító meglévő viselkedését. Abban az esetben, ha egy új funkció bevezetése szükségessé teszi a meglévő nyelvi specifikáció módosítását, az ilyen kompatibilitási törés csak akkor ésszerű, ha a hatás rendkívül minimális lenne, és a funkció előnyei magasak.

• Biztonság. Rendkívüli helyzetekben a biztonsági problémák kompatibilitási törést okozhatnak, például egy olyan funkció eltávolítását vagy módosítását, amely eredendően nem biztonságos, és egyértelmű biztonsági kockázatot jelent a felhasználók számára.

A kompatibilitási törések bevezetésének nem elfogadható okai a következő helyzetek:

• Nemkívánatos vagy sajnálatos viselkedés. A nyelvi tervezés vagy fordító viselkedése, amely ésszerű, de utólag nemkívánatosnak vagy sajnálatosnak tekinthető, nem indokolja a visszamenőleges kompatibilitás megszakadását. Ehelyett a nyelvi elavulás folyamatát kell használni.

• Bármi egyéb. Ellenkező esetben a fordító működése visszafelé kompatibilis marad.

Hatásfeltételek

Ha azt mérlegeli, hogy elfogadható-e egy kompatibilitási törés, több feltételt is figyelembe kell venni annak meghatározásához, hogy milyen hatással lehet a változás. Minél nagyobb a hatás, annál magasabb a kompatibilitási törések elfogadására szolgáló sáv.

A feltételek a következők:

• Mi a módosítás hatóköre? Más szóval, hány program valószínűleg érintett? Valószínűleg hány felhasználót érint? Milyen gyakori lesz a módosítás által érintett kód írása?

• Léteznek áthidaló megoldások, amelyek ugyanazt a viselkedést érik el a módosítás előtt?

• Mennyire nyilvánvaló a változás? A felhasználók azonnali visszajelzést kapnak arról, hogy valami megváltozott, vagy a programjaik csak másképp futnak?

• Meg lehet oldani a módosítást a frissítés során? Lehet-e olyan eszközt írni, amely tökéletes pontossággal megtalálhatja azt a helyzetet, amelyben a változás történik, és módosíthatja a kódot, hogy megkerülje a módosítást?

• Mi a közösség visszajelzése a változásról?

Nyelvi elavulás

Idővel a nyelv vagy a fordító egyes részei elavulttá válhatnak. Ahogy korábban már említettem, az ilyen elavult funkciók eltávolítása nem elfogadható, ha megszakítja a kompatibilitást. Ehelyett a következő lépéseket kell követnie:

1. A Visual Studio A verziójában elérhető funkció miatt a felhasználói közösségnek visszajelzést kell kérnie a funkció elavulásáról, és a végleges elavulásról szóló döntés meghozatala előtt teljes körű értesítést kell kapnia. Az elavulás folyamata bármikor visszavonható vagy megszüntethető a felhasználói közösség visszajelzése alapján.

2. teljes verziójú (azaz nem pontkiadás) A Visual Studio B-jének olyan fordítói figyelmeztetésekkel kell megjelennie, amelyek figyelmeztetnek az elavult használatra. A figyelmeztetéseknek alapértelmezés szerint be kell kapcsolniuk, és ki is kapcsolhatók. Az elavulásokat egyértelműen dokumentálni kell a termékdokumentációban és a weben.

3. A Visual Studio teljes C-verzióját olyan fordítói figyelmeztetésekkel kell kiadni, amelyek nem kapcsolhatók ki.

4. Ezt követően a Visual Studio D teljes verzióját ki kell adni a fordítóhibákká konvertált elavult fordítói figyelmeztetésekkel. A D kiadásának az A kiadás általános támogatási fázisának (az írástól számított 5 év) befejezése után kell történnie.

5. Végül kiadható a Visual Studio E verziója, amely eltávolítja a fordítóhibákat.

Az elavulási keretrendszeren belül nem kezelhető módosítások nem engedélyezettek.