Si vous disposez d'ouvrages ou d'articles de référence ou si vous connaissez des sites web de qualité traitant du thème abordé ici, merci de compléter l'article en donnant les références utiles à sa vérifiabilité et en les liant à la section « Notes et références ».
Le sucre syntaxique exprime le fait de donner au programmeur des possibilités d'écriture plus succinctes ou plus intuitives.
Dans le langage Perl, par exemple, on peut omettre des parenthèses obligatoires dans d'autres langages :
print $a, $b, $c;
pour
print ($a, $b, $c);
Ce langage permet également d'écrire :
print "OK" if $debug;
pour
if ($debug) { print("OK");}
Le sucre syntaxique peut être facilement traduit (désucré) si l'on veut vraiment produire un programme dans la syntaxe de base, plus stricte et plus obscure, du langage. Un simple préprocesseur peut effectuer ce travail de désucrage. Par exemple, en C la notation tableau[i] est du sucre syntaxique pour l'expression *(tableau+i).
Les macros de Lisp ou Scheme permettent de sucrer, syntaxiquement parlant, des programmes écrits dans ces langages ; toutes sortes d'extensions syntaxiques y sont possibles.
Lorsqu'APL était intensivement utilisé dans les infocentres, chaque utilisateur se créait son sucre syntaxique en définissant ses propres opérateurs :
∇z←a if b
z←b/a
Sel syntaxique
On nomme par opposition sel syntaxique les fonctionnalités conçues pour rendre plus difficile l'écriture de programmes erronés[2],[3].
En pratique, le sel syntaxique est comme un passage obligé par lequel le programmeur doit passer pour prouver qu'il sait ce qu'il fait, sans que le code écrit pour cela n'exprime une action particulière du logiciel. Certains programmeurs considèrent l'obligation de déclarer les variables et leur type comme du sel syntaxique. De même, avoir à écrire fin si (ou fi), fin jusqu'à (end while), fin faire (end do ou od), etc. pour fermer le bloc d'instructions d'une instruction de contrôle au lieu de simplement écrire fin peut être considéré comme du sel syntaxique ; cette contrainte est particulièrement contre-productive si l'on ne dispose pas d'un éditeur syntaxique approprié, comme on peut s'en rendre compte lorsqu'on supprime un long bloc dans un programme. La suppression du début oblige en effet à un second travail de recherche, cette fois-ci de la fin du bloc, et de suppression de celle-ci, ce qui peut déconcentrer le programmeur. Si la fin était comme en PL/I de style :
end;
end;
end;
la suppression de n'importe lequel de ces end; ferait l'affaire. En Python, il n'existe pas de end pour marquer la fin d'une structure car c'est l'indentation qui définit un bloc.