Sucre syntaxique

Sucre syntaxique et sel syntaxique sont des expressions utilisées en informatique à propos des langages de programmation.

Sucre syntaxique

Sucre syntaxique est une expression imaginée par Peter J. Landin pour désigner les extensions à la syntaxe d'un langage de programmation qui :

• ne modifient pas son expressivité ;
• le rendent plus agréable à écrire comme à lire.

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).

L'utilisation de la notation infixe x+y peut être considérée aussi comme du sucre syntaxique pour la notation polonaise inverse x y +.

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.

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.