Meilleure réponse
Le sucre syntaxique, ou sucre de syntaxe, est un « raccourci » visuellement ou logiquement attrayant fourni par le langage, qui réduit la quantité de code à écrire dans certaines situations courantes.
Par exemple, lorsque vous définissez une variable sur une valeur qui dépend dune condition, dans un langage plus simple avec moins de «sucre», vous pouvez le faire ceci:
int a;
if(SomeFunction() == 2)
a = 4;
else
a = 9;
Cest un peu trop pour une opération aussi simple; dans des langages plus simples, les développeurs ont souvent créé une fonction « Inline If » pour envelopper cette logique dans quelque chose de plus concis:
public T Iif
{
if(condition) return ifTrue;
return ifFalse;
}
...
//usage
int a = Iif(SomeFunction() == 2, 4, 9);
Là, maintenant lutilisation réelle est beaucoup plus concise. De nombreux langages modernes, y compris C #, incorporent une opération comme celle-ci directement dans la spécification du langage sous la forme de « lopérateur conditionnel ternaire »:
int a = SomeFunction() == 2 ? 4 : 9;
Cet opérateur est un « sucre de syntaxe » fourni par le langage pour une opération conditionnelle.
Maintenant, un sous-cas courant de ce paramètre de variable conditionnelle est que si notre premier choix pour un moyen de produire une valeur pour définir la variable évalue comme nulle, nous devrions utiliser un autre moyen. Par exemple:
MyClass theClass = GetMyClass();
if(theClass == null)
theClass = FailSafeMyClassGetter();
Pas mal, mais nous pouvons améliorer cela:
MyClass theClass = GetMyClass() ?? FailSafeMyClassGetter();
Le « ?? » Lopérateur est connu sous le nom d « opérateur de fusion null » et il produit essentiellement la première valeur lue de gauche à droite qui nest pas nulle.
Un autre C # obtenu récemment était la « propriété automatique ». De manière succincte, C # a ce quon appelle des «propriétés»; paires de blocs de code qui représentent un « membre de données » dun objet, qui peuvent effectuer une validation ou une logique de calcul plus complexe quun simple champ ne le pourrait, mais qui sont accessibles comme si le membre était un champ au lieu dutiliser GetX () et SetX (), il devient donc facile de faire la différence dans le code lorsque vous accédez aux données et que vous effectuez des opérations. Il est recommandé en C #, pour des raisons de cohérence et de maintenance, dutiliser des propriétés au lieu de champs lors de limplémentation de membres de données visibles publiquement . Cependant, neuf fois sur dix, la propriété « encapsule » simplement une variable de champ privé, et conformément aux bonnes pratiques, limplémentation de la propriété pour une valeur de données simple pourrait ressembler à:
private int \_myIntProperty;
public int MyIntProperty
{
get
{
return \_myIntProperty;
}
set
{
\_myIntProperty = value;
}
}
Un peu moche, très répétitif et beaucoup plus de lignes de code que ce dont nous avons vraiment besoin. Il était tentant par le passé de renoncer meilleure pratique et utilisez simplement un champ dans ces cas simples, afin de réduire cette tentation et leffet néfaste quelle peut avoir sur la base de code si vous décidiez plus tard que vous aviez vraiment besoin dune propriété, les concepteurs de C # ont inclus du sucre de syntaxe dans le C # 3.0 spécification:
public int MyIntProperty { get; set; }
Cette déclaration de propriété est traitée comme étant la même que la déclaration ci-dessus, mais cest beaucoup plus rapide et plus facile décrire un classe pleine de ceux-ci plutôt que de le faire à lancienne, et cest aussi beaucoup plus facile à maintenir.
Ce ne sont que quelques exemples de «sucre de syntaxe» disponible en C #. Dautres incluent:
* Inférence de type de variable – var someInt = 5; – Le compilateur peut déterminer le type dune variable locale déclarée à partir de laffectation initiale, donc vous navez pas pour le spécifier explicitement (puis le modifier si le type dont vous avez besoin change).
* yield return – Une grande partie de la programmation .NET implique des collections dobjets, et faire des tâches répétitives sur chaque élément de la même chose. Limplémentation de linterface IEnumerable qui autorise diverses boucles intégrées telles que foreach pour fonctionner, nécessitant une seconde classe entière qui implémentait IEnumerator pour gérer litération dans la collection. Le mot-clé yield return a considérablement simplifié cela, en permettant à la logique ditérateur elle-même dêtre définie dans la propre méthode GetEnumerator () de la collection.
* async / await – De même, de plus en plus de tâches de programmation doivent être exécutées de manière « asynchrone » en donnant le travailler à un autre «fil» de lapplication, de sorte que le travail du programme peut être réparti entre les multiples processeurs du PC moderne, tandis que linterface utilisateur de lapplication reste «réactive» aux demandes du système dexploitation pour redessiner linterface utilisateur et effectuer autres tâches visuelles. Le concept de threading nest pas difficile à comprendre, mais jusquà C # 4.0, il fallait essentiellement diviser votre méthode en deux; une méthode démarre lopération asynchrone, puis une seconde est appelée lorsque le thread darrière-plan a terminé le travail. Pas plus; ces deux nouveaux mots-clés permettent de définir une fonction qui effectue un travail asynchrone de manière très synchrone, tandis que le compilateur effectue le fractionnement de méthode en arrière-plan lors de la construction du code.
Réponse
Il ny a pas de définition formelle du sucre syntaxique, cest une notion nébuleuse.
Le sucre syntaxique dans sa définition la plus acceptée est une syntaxe supplémentaire qui est immédiatement traduite en une forme plus primitive et plus lourde par le compilateur mais permet une expérience «plus douce» pour le programmeur dans lexpression de certaines instructions courantes.
Le problème avec cette définition est que la syntaxe «supplémentaire» nest pas une description très significative. Dans certains cas, il est assez clair que nous avons du sucre syntaxique, par exemple le rapport du langage Haskell définit explicitement certains éléments syntaxiques (do-blocks et list comprehensions) par leur traduction dans une syntaxe plus simple. Cest un cas assez clair de sucre syntaxique, ils existent uniquement pour faciliter lécriture dun programme, pas dans un sens profond dans la traduction du compilateur du programme en un arbre symbolique.
Dans dautres cas, cest beaucoup moins clair car le langage ne se soucie pas de ce genre de formalisation, par exemple les décorateurs en Python sont souvent décrits par la façon dont vous écririez le code équivalent sans eux mais pour autant que je sache, il nest jamais dit explicitement: «vous ne devrait pas compiler les décorateurs directement dans votre représentation intermédiaire, mais plutôt les traduire de cette manière au préalable ». Certaines implémentations de Python peuvent choisir de faire exactement cela, mais dautres peuvent avoir ajouté des décorateurs comme fonctionnalité de leur représentation intermédiaire.