Legjobb válasz
A szintaktikus cukor vagy a szintaxis cukor vizuálisan vagy logikailag vonzó “parancsikon”, amelyet a nyelv nyújt, amely csökkenti a kódok mennyiségét, amelyeket valamilyen általános helyzetben be kell írni.
Például, ha egy változót feltételhez kötött értékre állítunk, egyszerűbb nyelven, kevesebb „cukorral”, megtehetjük ez:
int a;
if(SomeFunction() == 2)
a = 4;
else
a = 9;
Ez egy kicsit sok egy ilyen egyszerű művelethez; egyszerűbb nyelveken a fejlesztők gyakran létrehoztak egy „Inline If” függvényt, hogy ezt a logikát tömörebbé tegyék:
public T Iif
{
if(condition) return ifTrue;
return ifFalse;
}
...
//usage
int a = Iif(SomeFunction() == 2, 4, 9);
Ott a tényleges használat most sokkal tömörebb. Számos modern nyelv, köztük a C #, egy ilyen műveletet közvetlenül a nyelv specifikációjába épít be a “háromfeltételes operátor” formájában:
int a = SomeFunction() == 2 ? 4 : 9;
Ez az operátor nyelv által biztosított “szintaxis cukor” egy feltételes művelethez.
Most ennek a feltételes változó-beállításnak egy általános alesete az, hogy ha az első választásunk egy eszköz létrehozására egy érték előállításához A null értékű változó beállításához alternatív eszközöket kell használnunk. Például:
MyClass theClass = GetMyClass();
if(theClass == null)
theClass = FailSafeMyClassGetter();
Nem rossz, de ezen javíthatunk:
MyClass theClass = GetMyClass() ?? FailSafeMyClassGetter();
A “??” Az operátor “null-koalízáló operátor” néven ismert, és alapvetően balról jobbra olvasható első értéket állít elő, amely nem nulla.
Egy másik C # nemrégiben az “automatikus tulajdonság” volt. Röviden, a C # rendelkezik úgynevezett “tulajdonságokkal”; olyan kódblokk-párok, amelyek egy objektum “adattagját” reprezentálják, amelyek bonyolultabb érvényesítési vagy számítási logikát képesek végrehajtani, mint egy egyszerű mező, de hozzáférhetők úgy, mintha a tag mező lenne, a GetX () és a SetX használata helyett. () metódus hív, így könnyen megkülönböztethetővé válik a kódban, amikor “újból hozzáfér az adatokhoz, mint a műveletek végrehajtásához. A C # -ben bevált gyakorlat, konzisztencia és karbantartási okokból a mezők helyett tulajdonságokat kell használni a nyilvánosan látható adattagok megvalósításakor. . Tízből kilencszer azonban a tulajdonság csak egy privát mezőváltozót „csomagol be”, és így a bevált gyakorlatot követve az egyszerű adatérték tulajdonságainak megvalósítása a következőképpen nézhet ki:
private int \_myIntProperty;
iv
{
get
{
return \_myIntProperty;
}
set
{
\_myIntProperty = value;
}
}
Olyan csúnya, nagyon ismétlődő és sokkal több kódsor, mint amire valójában szükségünk lenne. A múltban csábító volt lemondani a legjobb gyakorlat, és csak egy mezőt használjon ezekben az egyszerű esetekben, így csökkentve ezt a kísértést és a kódbázisra gyakorolt káros hatását, ha később úgy döntött, hogy valóban szüksége van egy tulajdonságra, a C # tervezői szintaxis cukrot tartalmaztak a C # 3.0-ban. specifikáció:
public int MyIntProperty { get; set; }
Ezt a tulajdonságnyilatkozatot a fenti deklarációval megegyezőnek tekintjük, de sokkal gyorsabb és könnyebb osztály tele van ezekkel, mint a régi módon csinálni, és sokkal könnyebb fenntartani is.
Ez csak néhány példa a C # nyelven elérhető “szintaxis cukorra”. A következők a következők:
* Változótípus következtetés – var someInt = 5; – A fordító a kezdeti hozzárendelésből meghatározhatja a deklarált helyi változó típusát, így Önnek nincs kifejezett megadásához (majd megváltoztatásához, ha a szükséges típus megváltozik).
* yield return – Sok .NET programozás objektumgyűjteményeket tartalmaz, és ismétlődő feladatokat hajt végre ugyanazon elemeken. Régebben eléggé érintett folyamat volt a IEnumerable interfész megvalósítása, amely lehetővé teszi különféle beépített hurkok, például foreach működéséhez egy teljes második osztályra van szükség, amely megvalósítja a IEnumerator alkalmazást az iteráció kezelésére a gyűjteményen keresztül. A yield return kulcsszó drámai módon egyszerűsítette ezt azáltal, hogy lehetővé teszi az iterátor logika meghatározását a gyűjtemény saját GetEnumerator () metódusán belül.
* async / await – Hasonlóképpen, egyre több programozási feladatot kell “aszinkron” futtatni a dolgozzon az alkalmazás egy másik “szálán”, így a program munkája felosztható a modern processzor több processzora között, miközben az alkalmazás felhasználói felülete továbbra is “reagál” az operációs rendszer kéréseire, hogy újrarajzolják a felhasználói felületet és végrehajtják egyéb vizuális feladatok. A menetfúrás fogalmát nem nehéz megérteni, de a C # 4.0-ig lényegében a módszer kettéhasítását igényelte; az egyik módszer elindítja az aszinkron műveletet, majd egy másodikat hívunk meg, amikor a háttérszál befejezte a munkát. Nem több; ez a két új kulcsszó lehetővé teszi az aszinkron munkát végző függvény nagyon szinkron megjelenésű meghatározását, míg a fordító a kód felépítésekor a módszerek felosztását végzi a színfalak mögött.
Válasz
A szintaktikus cukornak nincs hivatalos definíciója, ez egy ködös fogalom.
A szintaktikus cukor a legelfogadottabb definíciójában extra szintaxis, amelyet a fordító azonnal primitívebb és nehézkesebb formába fordít, de lehetővé teszi a „kedvesebb” élményt a programozó számára bizonyos általános utasítások kifejezésében.
Ezzel a definícióval az a probléma, hogy az „extra” szintaxis nem túl értelmes leírás. Bizonyos esetekben teljesen egyértelmű, hogy szintaktikai cukorral rendelkezünk, például a Haskell nyelvű jelentés kifejezetten meghatároz bizonyos szintaktikai elemeket (do-blokkokat és a szövegértéseket) egyszerűbb szintaxissal történő fordítással. Ez a szintaktikai cukor meglehetősen világos esete, csak a program írásának megkönnyítésére léteznek, semmilyen mély értelmezésben nem a program fordítójának szimbolikus fává történő fordításában.
Más esetekben, ez sokkal kevésbé egyértelmű, mert a nyelv nem zavarja az ilyen formalizálást, például a Python dekorátorait gyakran leírják, hogyan írná nélkülük az egyenértékű kódot, de amennyire tudom, soha nem mondják ki kifejezetten: „te nem szabad közvetlenül a köztes ábrázolásodba fordítanod a dekoratőröket, hanem előzőleg ilyen módon lefordítanod őket ”. A Python egyes megvalósításai dönthetnek úgy, hogy ezt megcsinálják, de más is előfordulhat, hogy a dekorátorokat a köztes ábrázolásuk jellemzőjeként alkalmazta