Nejlepší odpověď
Syntaktický cukr nebo syntaktický cukr je vizuálně nebo logicky přitažlivá „zkratka“ poskytnutá jazykem, která snižuje množství kódu, který musí být napsán v běžné situaci.
Například při nastavování proměnné na hodnotu, která je závislá na podmínce, můžete v jednodušším jazyce s menším množstvím cukru udělat toto:
int a;
if(SomeFunction() == 2)
a = 4;
else
a = 9;
To je pro tak jednoduchou operaci trochu moc; v jednodušších jazycích vývojáři často vytvořili funkci „Inline If“, která tuto logiku zabalí do něčeho stručnějšího:
public T Iif
{
if(condition) return ifTrue;
return ifFalse;
}
...
//usage
int a = Iif(SomeFunction() == 2, 4, 9);
Tam je nyní skutečné využití mnohem výstižnější. Mnoho moderních jazyků včetně C # začleňuje operaci jako je tato přímo do specifikace jazyka ve formě „ternárního podmíněného operátoru“:
int a = SomeFunction() == 2 ? 4 : 9;
Tento operátor je jazykem poskytovaný „syntaxový cukr“ pro podmíněnou operaci.
Nyní je běžným dílčím případem tohoto podmíněného nastavení proměnné, že pokud je naší první volbou prostředku k vytvoření hodnoty k nastavení proměnné se vyhodnotí jako null, měli bychom použít alternativní prostředky. Například:
MyClass theClass = GetMyClass();
if(theClass == null)
theClass = FailSafeMyClassGetter();
To není špatné, ale můžeme to vylepšit:
MyClass theClass = GetMyClass() ?? FailSafeMyClassGetter();
„??“ operátor je známý jako „null-coalescing operator“ a v zásadě vytváří první hodnotu při čtení zleva doprava, která není null.
Dalším C #, který byl nedávno získán, byla „auto-vlastnost“. Stručně řečeno, C # má takzvané vlastnosti; dvojice kódových bloků, které představují „datový člen“ objektu, který může provádět složitější logiku ověřování nebo výpočtu než jednoduché pole, ale k nim lze přistupovat, jako by byl člen namísto použití GetX () a SetX Metoda () volá, takže je snadné rozlišit v kódu, když „přistupujete k datům versus provádění operací. Nejlepším postupem v C # je z důvodu konzistence a údržby použití vlastností místo polí při implementaci veřejně viditelných datových členů . Devětkrát z deseti však vlastnost pouze „zabalí“ proměnnou soukromého pole, a tak podle osvědčených postupů může implementace vlastnosti pro jednoduchou datovou hodnotu vypadat takto:
private int \_myIntProperty;
public int MyIntProperty
{
get
{
return \_myIntProperty;
}
set
{
\_myIntProperty = value;
}
}
Druh ošklivých, velmi opakujících se a způsobů více řádků kódu, než skutečně potřebujeme. V minulosti bylo lákavé vzdát se osvědčený postup a v těchto jednoduchých případech stačí použít pole, aby se snížilo pokušení a nepříznivý vliv, který může mít na základ kódu, pokud jste se později rozhodli, že opravdu potřebujete nějakou vlastnost, návrháři jazyka C # zahrnuli do jazyka C # 3.0 nějaký syntaxový cukr specifikace:
public int MyIntProperty { get; set; }
S touto deklarací vlastnosti se zachází jako s výše uvedenou deklarací, ale její psaní je mnohem rychlejší a snazší třída plná těchto věcí, než to dělat starým způsobem, a je také mnohem snazší udržovat je.
Toto je jen několik příkladů „syntaxového cukru“ dostupného v C #. Mezi další patří:
* Odvození typu proměnné – var someInt = 5; – kompilátor může určit typ deklarované místní proměnné z původního přiřazení, takže ji nemáte explicitně jej určit (a poté jej změnit, pokud se typ, který potřebujete, změní).
* yield return – Mnoho programování .NET zahrnuje kolekce objektů a dělat opakující se úkoly na každém prvku téhož. Býval to docela zapojený proces implementace IEnumerable rozhraní, které umožňuje různé integrované smyčky jako foreach fungovat, což vyžaduje celou druhou třídu, která implementovala IEnumerator zpracování iterace prostřednictvím kolekce. Klíčové slovo yield return to dramaticky zjednodušilo, povolením definování samotné logiky iterátoru v rámci vlastní metody GetEnumerator () kolekce.
* async / await – Podobně stále více programovacích úkolů musí být spuštěno „asynchronně“ zadáním pracovat na jiném „vláknu“ aplikace, takže práci programu lze rozdělit mezi více procesorů v moderním počítači, zatímco uživatelské rozhraní aplikace zůstává „citlivé“ na požadavky OS na překreslení uživatelského rozhraní a provádění další vizuální úkoly. Koncept vlákna není těžké pochopit, ale až do C # 4.0 to v zásadě vyžadovalo rozdělení metody na dvě; jedna metoda spustí asynchronní operaci, poté se zavolá druhá, když vlákno na pozadí dokončí práci. Už ne; tato dvě nová klíčová slova umožňují definovat funkci, která provádí asynchronní práci velmi synchronně, zatímco kompilátor při vytváření kódu provádí dělení metod v zákulisí.
Odpovědět
Neexistuje žádná formální definice syntaktického cukru, jedná se o mlhavou představu.
Syntaktický cukr ve své nejpřijímanější definici je zvláštní syntax, kterou překladač okamžitě přeloží do primitivnější a těžkopádnější podoby, ale umožňuje programátorovi „sladší“ zážitek při vyjadřování určitých běžných pokynů.
Problém s touto definicí spočívá v tom, že „extra“ syntaxe není příliš smysluplným popisem. V některých případech je zcela jasné, že máme syntaktický cukr, například zpráva z jazyka Haskell výslovně definuje určité syntaktické prvky (do-bloky a seznamy s porozuměním) jejich překladem do jednodušší syntaxe. Toto je docela jasný případ syntaktického cukru, existují pouze proto, aby usnadnily psaní programu, nikoli v hlubokém smyslu při překladu programu do symbolického stromu.
V ostatních případech je to mnohem méně jasné, protože jazyk se s tímto druhem formalizace neobtěžuje, například dekoratéři v Pythonu jsou často popsáni tím, jak byste bez nich napsali ekvivalentní kód, ale pokud vím, nikdy to není výslovně řečeno: „vy by neměla kompilovat dekoratéry přímo do vaší mezilehlé reprezentace, ale raději je předem tímto způsobem překládat “. Některá implementace Pythonu se může rozhodnout, že to udělá, ale jiná možná přidala dekoratéry jako rys své zprostředkující reprezentace.