La coloration syntaxique fait-elle réellement une différence ?
La mise en évidence de la syntaxe rend votre code joli, n'est-ce pas ? Mais s’agit-il simplement d’une subtilité esthétique ou a-t-il un impact plus fonctionnel ? Et existe-t-il des moyens de l'améliorer ?
Sommaire
Qu’est-ce que la coloration syntaxique ?
Il y a bien longtemps, lorsque j’ai appris à programmer, le code ressemblait à ceci :
Les écrans étaient basse résolution, à faible rafraîchissement et résolument monochromes. Parfois, votre code était bleu clair sur bleu foncé, parfois vert sur noir, mais il s'agissait toujours d'une seule police, d'une seule couleur. Je ne sais pas combien de temps j'ai supporté cela, mais ma meilleure hypothèse est que j'ai commencé à utiliser la coloration syntaxique au début des années 2000, lorsque l'éditeur TextPad l'a ajouté en tant que fonctionnalité. Aujourd'hui, mon code ressemble à ceci :
Je trouve cela beaucoup plus agréable à utiliser, même si je n'y pense pas souvent : la coloration syntaxique est juste là, une fonctionnalité omniprésente dans presque tous les éditeurs que je souhaite utiliser. Depuis que les émulateurs de terminaux ont finalement réussi à déchiffrer la couleur, j'ai à peine eu à faire face à une session de codage monochrome, que je sois dans un IDE GUI avec toutes les cloches et sifflets, ou dans le bon vieux Vim fiable.
Pour un œil non averti, la coloration syntaxique n'est qu'une autre affectation que nous, les programmeurs, aimons adopter, un peu comme les claviers avec rétroéclairage couleur ou les boîtiers PC transparents. Mais cela constitue l’erreur fondamentale selon laquelle la coloration syntaxique ne fait que pulvériser des couleurs aléatoires sur tout. C'est assez juste, si vous ne comprenez pas le code qui se cache derrière, cela peut ressembler à ça, mais la coloration syntaxique n'est pas du tout aléatoire. Le problème est ce mot « syntaxe » : la coloration syntaxique reflète la structure sous-jacente de notre code, et cela peut être très utile.
Comment puis-je utiliser la coloration syntaxique ?
Pour commencer, sachez que pratiquement n’importe quel éditeur moderne, dans n’importe quel environnement, devrait prendre en charge la coloration syntaxique. Si ce n’est pas le cas, il est probablement temps de procéder à une mise à niveau. En fait, les seuls éditeurs que je connais qui ne prennent pas en charge la coloration syntaxique sont le Bloc-notes Windows et macOS TextEdit. Sérieusement, si vous utilisez toujours l'un ou l'autre pour la programmation, arrêtez-vous et choisissez un meilleur éditeur dès maintenant !
Avec un éditeur de texte approprié en main, essayez d'ouvrir un fichier .c, un fichier .js ou tout autre fichier contenant du code dans la langue de votre choix. Il y a de fortes chances que votre éditeur soit configuré pour détecter le type de langue et appliquer automatiquement la coloration syntaxique.
Si vous n'avez vraiment pas de chance, votre éditeur peut être configuré sans coloration syntaxique par défaut, mais cela devrait être facile à modifier. Par exemple, l'éditeur Vim lira les paramètres d'un fichier de configuration comme /etc/vim/vimrc ou ~/.vimrc. Sur mon système Ubuntu, la section correspondante ressemble à ceci :
En fait, cela revient à dire « si la coloration syntaxique est disponible, activez-la ». Vous pouvez également activer/désactiver la mise en surbrillance dans votre session Vim actuelle : appuyez simplement sur deux points pour passer en mode ligne, puis tapez syntaxe désactivée ou syntaxe sur.
Bien que je parle principalement de couleur dans cet article, certains éditeurs et polices vont encore plus loin, vous permettant de surligner avec du gras, du souligné et d'autres formats.
La coloration syntaxique est-elle bénéfique ?
Les résultats de cette étude sur l’impact de la coloration syntaxique suggèrent que la coloration syntaxique réduit le temps d’exécution des tâches. L'expérience a utilisé le suivi oculaire pour déterminer que la coloration syntaxique aidait les participants à se concentrer sur des parties plus importantes du code.
Dans ma propre utilisation, il y a un avantage qui revient encore et encore, qui peut ne pas sembler immédiatement évident : les erreurs de syntaxe. Prenons cet exemple de code :
Vous ne remarquerez peut-être pas immédiatement l'erreur de syntaxe, mais la surbrillance des couleurs devrait la rendre beaucoup plus évidente :
Avec la coloration syntaxique, il est facile de remarquer la couleur violette jusqu'à la fin de la ligne, où elle inclut la parenthèse fermante et le caractère point-virgule. Il s'agit d'un signe d'avertissement clair indiquant qu'il y a une erreur plus tôt dans la ligne. Lorsque le bug est corrigé, le résultat apparaît comme il se doit, la couleur violette devenant blanche une fois le guillemet correct en place :
Avec le temps, j'ai appris à repérer plus efficacement ce type d'erreurs, grâce à la coloration syntaxique. Cela s'est produit inconsciemment, mais mon cerveau semble maintenant sensible aux différences de syntaxe que la mise en évidence des couleurs met en évidence. Le code surligné en couleur semble simplement « plus faux » lorsque des erreurs de syntaxe sont présentes.
Y a-t-il des inconvénients ?
Bien entendu, certains programmeurs peuvent avoir plus de mal à distinguer les couleurs et certaines combinaisons de couleurs en particulier. Cela ne rendrait pas nécessairement les choses pires que le code monochrome, mais cela aurait certainement un impact sur les gains éventuels.
Certaines personnes peuvent souffrir de troubles cognitifs qui amplifient les distractions, et la mise en évidence des couleurs peut en être une. Il existe différentes techniques pour encourager la concentration, vous pourrez donc peut-être atténuer ce problème, mais cela vaut la peine d'expérimenter la coloration syntaxique pour juger par vous-même des avantages.
En théorie, la coloration syntaxique s'accompagne d'une baisse de performances, mais vous ne devriez pas le remarquer à moins que vous ne travailliez avec des fichiers volumineux, auquel cas vous aurez probablement de plus gros problèmes ! Si vous respectez de bons principes de programmation et utilisez un éditeur de texte stable et établi, il est peu probable que vous remarquiez de tels problèmes.
La coloration syntaxique était auparavant plus délicate à mettre en œuvre. Non seulement un éditeur doit comprendre la syntaxe d'un langage, mais il doit également gérer une partie du code lors de son édition. Une approche naïve pourrait entraîner des changements de couleur fréquents et gênants sur de gros blocs de texte.
Avec l’avènement du Language Server Protocol, une initiative de Microsoft, ce problème est moins préoccupant. De nos jours, les éditeurs de texte de Vim à Sublime Text prennent en charge LSP intégré, permettant des fonctionnalités telles que la complétion de code avancée et une coloration syntaxique parfaite. Mais si un éditeur communique avec un serveur de langue distant via un réseau, une certaine latence peut être introduite.
Les véritables avantages de la coloration syntaxique ne sont pas bien compris, tout comme les facteurs qui les affectent. Par exemple, si vous changez fréquemment d'éditeur, ils peuvent utiliser des jeux de couleurs différents, voire aucun, ou des méthodes de surbrillance différentes. Cela pourrait réduire les avantages, voire les neutraliser.
Et qu’en est-il de la mise en évidence sémantique ?
Aussi efficace que puisse paraître la coloration syntaxique, ce n’est pas une baguette magique. En fait, des avancées similaires dans les éditeurs de texte, comme la correction automatique et la complétion de code, améliorent probablement davantage la durée de vie de votre programmation que la couleur. Mais certaines personnes ont émis l’hypothèse que la coloration syntaxique n’est qu’un début et que la couleur peut être utilisée de manière plus avancée.
Une de ces alternatives est appelée mise en évidence sémantique. Cette fonctionnalité est en fait présente dans des outils tels que Visual Studio et Xcode, même si vous ne la connaissez peut-être pas. La mise en évidence sémantique se concentre davantage sur la signification sous-jacente de votre code que sur sa syntaxe.
La différence entre la coloration syntaxique et la coloration sémantique est subtile mais peut-être significative. Prenons cet exemple d'extrait de code mis en évidence par la syntaxe :
Notez exactement quels jetons sont mis en surbrillance : des mots-clés comme function, let et if ; des valeurs scalaires telles que 1, 0 et la chaîne ; et des caractères de syntaxe comme ( et {. Maintenant, jetez un œil à un extrait équivalent avec une mise en évidence sémantique, qui pourrait ressembler à ceci :
Cette fois, seuls les noms (fonctions, variables locales et paramètres) sont mis en surbrillance, mais chacun est mis en surbrillance dans une couleur différente. Cela permet de repérer plus facilement la durée de vie d'une variable et d'identifier les fautes de frappe susceptibles de modifier son nom. C'est comme une toute autre façon de visualiser la structure du code, simplement en changeant la palette de couleurs.
La mise en évidence de la syntaxe est une innovation pratique dont j'ai vu devenir la valeur par défaut. Avec l’adoption du LSP et les progrès de l’IA, ce n’est que le début. Jamais auparavant il n’a été aussi facile et aussi esthétique d’être programmeur.
