Paras vastaus
Syntaktinen sokeri tai syntaksisokeri on visuaalisesti tai loogisesti houkutteleva ”pikakuvake”, jonka tarjoaa kieli, joka vähentää kirjoitettavan koodin määrää joissakin yleisissä tilanteissa.
Esimerkiksi kun asetat muuttujalle arvon, joka on riippuvainen ehdosta, yksinkertaisemmalla kielellä, jossa on vähemmän ”sokeria”, voit tehdä tämä:
int a;
if(SomeFunction() == 2)
a = 4;
else
a = 9;
Tämä on vähän paljon niin yksinkertaisesta toiminnasta; yksinkertaisemmilla kielillä kehittäjät loivat usein ”Inline If” -toiminnon käärimään tämän logiikan johonkin tiiviimpään:
public T Iif
{
if(condition) return ifTrue;
return ifFalse;
}
...
//usage
int a = Iif(SomeFunction() == 2, 4, 9);
Tässä todellinen käyttö on nyt paljon suppeampaa. Monet modernit kielet, mukaan lukien C #, sisällyttävät tämän kaltaisen operaation suoraan kielitietoihin ”ternäärisen ehdollisen operaattorin” muodossa:
int a = SomeFunction() == 2 ? 4 : 9;
Tämä operaattori on kielen toimittama ”syntaksisokeri” ehdolliselle toiminnolle.
Tämän ehdollisen muuttujan asetuksen yleinen tapaustapa on, että jos ensimmäinen valinta keinoksi tuottaa arvo Jos haluat asettaa muuttujan arvoksi nolla, meidän tulisi käyttää vaihtoehtoisia keinoja. Esimerkiksi:
MyClass theClass = GetMyClass();
if(theClass == null)
theClass = FailSafeMyClassGetter();
Ei paha, mutta voimme parantaa sitä:
MyClass theClass = GetMyClass() ?? FailSafeMyClassGetter();
”??” operaattori tunnetaan nimellä ”null-coalescing operator” ja se tuottaa pohjimmiltaan ensimmäisen arvon vasemmalta oikealle luettuna, joka ei ole nolla.
Toinen C # sai äskettäin ”auto-ominaisuus”. Lyhyesti sanottuna C #: lla on niin sanottuja ”ominaisuuksia”; pari koodilohkoja, jotka edustavat objektin ”datajäsentä”, jotka voivat suorittaa monimutkaisemman validoinnin tai laskentalogiikan kuin yksinkertainen kenttä voisi, mutta joihin pääsee käsiksi ikään kuin jäsen olisi kenttä GetX (): n ja SetX: n sijaan. () -metodikutsut, joten koodin erottaminen on helppoa, kun ”etsit tietoja uudelleen kuin suoritat toimintoja.” C: n paras käytäntö C #: ssä on johdonmukaisuuden ja ylläpitosyiden vuoksi käyttää ominaisuuksia kenttien sijasta, kun toteutetaan yleisesti näkyviä tietojäseniä . Yhdeksän kertaa kymmenestä ominaisuus kuitenkin vain ”kääri” yksityisen kenttämuuttujan, joten parhaiden käytäntöjen mukaisesti yksinkertaisen data-arvon ominaisuuden toteutus saattaa näyttää tältä:
private int \_myIntProperty;
public int MyIntProperty
{
get
{
return \_myIntProperty;
}
set
{
\_myIntProperty = value;
}
}
Eräänlainen ruma, hyvin toistuva ja paljon enemmän koodiriviä kuin mitä todella tarvitsemme. Aiemmin oli houkuttelevaa luopua paras käytäntö ja käytä vain kenttää näissä yksinkertaisissa tapauksissa, jotta voit vähentää kiusausta ja haitallista vaikutusta, joka sillä voi olla koodikantaan, jos myöhemmin päätit, että todella tarvitset ominaisuutta, C #: n suunnittelijat sisällyttivät syntaksisokeria C # 3.0: een. erittely:
public int MyIntProperty { get; set; }
Tämän ominaisuusilmoituksen katsotaan olevan sama kuin yllä oleva ilmoitus, mutta sen kirjoittaminen on paljon nopeampaa ja helpompaa luokka täynnä näitä kuin tehdä se vanhalla tavalla, ja sitä on myös paljon helpompi ylläpitää.
Nämä ovat vain muutama esimerkki ”syntaksisokerista”, joka on saatavana C #: ssä. Muita ovat:
* Muuttujatyyppien päättely – var someInt = 5; – Kääntäjä voi määrittää ilmoitetun paikallisen muuttujan tyypin alkuperäisestä tehtävästä, joten sinulla ei ole määrittää se nimenomaisesti (ja sitten muuttaa sitä, jos tarvitsemasi tyyppi muuttuu).
* yield return – Paljon .NET-ohjelmointiin liittyy objektien kokoelmia, ja toistuvien tehtävien tekeminen saman kullekin elementille. Aikaisemmin oli melko mukana prosessi IEnumerable -rajapinnan toteuttamiseksi, joka sallii erilaisia sisäänrakennettuja silmukoita, kuten foreach toimimaan, mikä vaatii koko toisen luokan, joka toteutti IEnumerator, käsittelemään iterointia kokoelman kautta. yield return -hakusana yksinkertaisti dramaattisesti sitä, antamalla iteraattori-logiikan itse määritellä kokoelman omassa GetEnumerator () -menetelmässä.
* async / await – Vastaavasti yhä useammat ohjelmointitehtävät on suoritettava ”asynkronisesti” antamalla työskennellä sovelluksen toisen ”säikeen” kanssa, joten ohjelman työ voidaan jakaa nykyaikaisen tietokoneen useiden prosessorien kesken, kun taas sovelluksen käyttöliittymä pysyy ”reagoivana” käyttöjärjestelmän pyyntöihin piirtää käyttöliittymä ja suorittaa muut visuaaliset tehtävät. Langoittamisen käsitettä ei ole vaikea ymmärtää, mutta ennen C # 4.0: ta se edellytti olennaisesti menetelmän jakamista kahtia; yksi menetelmä aloittaa asynkronisen toiminnan, sitten toinen kutsutaan, kun taustalanka on valmis. Ei enempää; näiden kahden uuden avainsanan avulla asynkronista työtä tekevä toiminto voidaan määritellä hyvin synkronisesti näyttävällä tavalla, kun taas kääntäjä jakaa menetelmän kulissien takana koodia rakennettaessa.
Vastaa
Syntaktisen sokerin muodollista määritelmää ei ole, tämä on hämärä käsite.
Syntaktinen sokeri on hyväksytyimmässä määritelmässään ylimääräinen syntakse, jonka kääntäjä kääntää välittömästi primitiivisemmäksi ja hankalammaksi muodoksi, mutta mahdollistaa ”suloisemman” kokemuksen ohjelmoijalle ilmaista tiettyjä yleisiä ohjeita.
Tämän määritelmän ongelmana on, että ”ylimääräinen” syntaksilla ei ole kovin mielekästä kuvausta. Tietyissä tapauksissa on melko selvää, että meillä on syntaktista sokeria, esimerkiksi Haskell-kieliraportti määrittelee nimenomaisesti tietyt syntaktiset elementit (do-lohkot ja luettelon ymmärrykset) niiden käännöksellä yksinkertaisemmaksi syntaksiksi. Tämä on melko selkeä syntaktisen sokerin tapaus, se on olemassa vain ohjelman kirjoittamisen helpottamiseksi, ei missään syvällisessä mielessä ohjelman kääntäjän käännöksessä symboliseksi puuksi.
Muissa tapauksissa se on paljon vähemmän selkeä, koska kieli ei vaivaudu tällaiseen virallistamiseen, esimerkiksi Pythonin sisustajia kuvataan usein kuinka kirjoitat vastaavan koodin ilman heitä, mutta sikäli kuin tiedän, sitä ei koskaan nimenomaisesti sanota: ”sinä ei pitäisi kääntää sisustajia suoraan välituotteeseesi, vaan kääntää ne etukäteen tällä tavalla ”. Jotkut Python-sovellukset saattavat päättää tehdä juuri niin, mutta toiset ovat saattaneet lisätä sisustajia väliesityksen ominaisuutena.