Un éditeur qui se contente d'être un éditeur

Visual Studio Code est un éditeur de code gratuit et open source de Microsoft, qui fonctionne sous Windows, Mac et Linux. La version décrite ici est 1.139. Le mot qui décide s'il vous convient est le dernier : éditeur. Il ouvre un dossier et modifie les fichiers qu'il contient. Il n'exige pas de posséder le projet, de générer une solution ni de redéfinir la manière dont le code est construit.

Cette retenue explique sa diffusion dans des langages pour lesquels il n'a jamais été conçu. Une chaîne de compilation, un script shell, un fichier de configuration et une feuille de style se travaillent dans la même fenêtre, avec les mêmes habitudes, parce que le programme ne cherche à faire autorité sur aucun d'eux.

Les quatre choses que l'on remarque d'abord

La coloration syntaxique est l'entrée : la structure devient visible avant d'être lue, et une parenthèse manquante cesse d'être une énigme. La complétion est la deuxième — pas seulement les noms qui existent, mais les signatures et les courtes explications, ce qui raccourcit le trajet entre se souvenir de quelque chose et l'utiliser.

Les raccourcis personnalisés sont la troisième, et la fonction que l'on sous-estime avant de l'utiliser puis dont on dépend. Tous les éditeurs ont des raccourcis ; la question utile est de savoir si ceux que vos doigts connaissent déjà peuvent y être associés, pour que changer d'éditeur ne signifie pas réapprendre à taper.

La comparaison est la quatrième, et la moins décorative. Deux fichiers, ou deux versions d'un même fichier, côte à côte avec les différences signalées : c'est la réponse la plus rapide à la seule question qui compte après une modification — qu'est-ce que je viens exactement de faire. Pouvoir lire cette réponse en dix secondes, au lieu de relire le fichier entier en espérant reconnaître ce qui a bougé, fait toute la différence entre relire et vérifier.

Tout le reste arrive en extension

Ce que l'éditeur ne fait pas lui-même arrive sous forme d'extension, via une place de marché intégrée au programme. Prise en charge d'un langage obscur, linter, adaptateur de débogage, thème, formateur : l'installation de base est volontairement mince, et les extensions en font un environnement de travail pour une pile donnée.

Le compromis est honnête et mérite d'être nommé : un éditeur mince plus quinze extensions n'est pas le même programme qu'un éditeur mince, et le temps de démarrage comme le bruit croissent avec la liste. L'habitude qui le garde agréable consiste à installer ce qui sert ce mois-ci et à retirer ce qui servait l'an dernier. Une liste qu'on ne nettoie jamais finit par se voir au démarrage : l'éditeur met alors plus de temps à s'ouvrir que le projet qu'on voulait regarder, et le premier réflexe devient de fermer des fenêtres.

Un détail sur la langue de l'interface

L'interface est en anglais par défaut, et les autres langues sont fournies sous forme d'extensions de langue plutôt qu'intégrées. C'est un choix assumé, avec une conséquence pratique : l'éditeur n'embarque pas la traduction de toutes les langues dans lesquelles il pourrait un jour servir, et une équipe peut fixer une langue d'interface indépendamment du système que chacun utilise.

Où l'éditeur s'arrête et où l'IDE commence

Honnêtement résumé, c'est un éditeur doté d'un très bon système d'extensions, et non un environnement de développement intégré au sens ancien. Il ne gère pas de lui-même un graphe de build, une migration de base de données ou un déploiement, et ce n'est pas là que se définit la structure d'une grosse solution. Il rend le fichier devant vous plus facile à modifier, sur les trois plateformes, sans compte et sans que le reste de l'équipe ait à se mettre d'accord.

Pour la plupart du travail, c'est l'exigence entière — et c'est précisément pourquoi il est devenu la réponse par défaut à la question de savoir avec quoi ouvrir un fichier.