L'éditeur de code

Où on va

Un éditeur de code n'est pas un traitement de texte pour programmeurs. C'est un outil qui lit votre projet, en comprend la structure, et sait répondre à des questions que vous vous poserez cent fois par jour : où cette fonction est-elle définie, qui l'appelle, quel est le type de cette variable, où ai-je écrit ce mot. Ce chapitre porte sur Visual Studio Code, mais tout ce qui suit se transpose à un autre éditeur, parce que les idées sont les mêmes.

Trois familles d'outils

Définition

Un éditeur de texte manipule des caractères. Bloc-notes, nano.

Un éditeur de code manipule du texte en connaissant le langage : coloration, complétion, navigation, diagnostic. VS Code, Sublime Text, Neovim configuré.

Un environnement de développement intégré, ou EDI, ajoute la chaîne complète de construction : compilation, débogueur, gestion de projet, souvent liée à un écosystème. Visual Studio, IntelliJ, Eclipse.

La frontière entre les deux derniers s'est effacée. VS Code, à l'origine un éditeur, exécute et débogue par ses extensions. Ce qui compte n'est pas l'étiquette mais ce que l'outil sait de votre code.

Ouvrir un projet, pas un fichier

C'est le premier réflexe à prendre, et il n'est pas évident quand on vient d'un traitement de texte.

Ouvrir un fichier seul donne un éditeur de texte coloré. Ouvrir le dossier du projet donne autre chose : l'outil voit tous les fichiers, la configuration du projet, le dépôt Git, les dépendances déclarées. La complétion propose alors vos propres fonctions, la recherche porte sur l'ensemble, et le saut vers une définition fonctionne.

Terminal2 commandes

$code .# ouvre le dossier courant comme espace de travail

$code projet/# ouvre ce dossier

Le dossier à ouvrir est celui de la racine du projet

Celui qui contient le .git, le fichier de dépendances, le README. Ouvrir un sous-dossier prive l'outil du contexte, et ouvrir le dossier parent qui contient dix projets ralentit tout et brouille la recherche.

Se déplacer sans la souris

Trois raccourcis remplacent l'essentiel de la navigation. Ils portent des noms différents selon les éditeurs, jamais des idées différentes.

Raccourci	macOS	Ce qu'il ouvre	Ce qu'on y cherche
`Ctrl+P`	`Cmd+P`	recherche de fichier	un fichier par un fragment de son nom
`Ctrl+Shift+P`	`Cmd+Shift+P`	palette de commandes	une commande dont on ignore le raccourci
`Ctrl+Shift+F`	`Cmd+Shift+F`	recherche globale	une chaîne dans tout le projet
`Ctrl+Shift+O`	`Cmd+Shift+O`	symboles du fichier	une fonction dans un fichier long
`F12`	`F12`	saut vers la définition	où ce symbole est défini
`Alt+F12`	`Opt+F12`	aperçu de la définition	la même chose, sans quitter la page
`Shift+F12`	`Shift+F12`	liste des références	qui utilise ce symbole
`Ctrl+ù`	`Ctrl+``	terminal intégré	une commande, dans le dossier du projet

La palette de commandes mérite une mention particulière : elle donne accès à toutes les commandes de l'éditeur et de ses extensions par leur nom. Tant qu'on ne la connaît pas, on cherche dans les menus ; ensuite, on cherche par mots. C'est le seul raccourci vraiment indispensable, parce qu'il donne accès à tous les autres.

Les raccourcis d'édition qui font gagner le plus

Raccourci	macOS	Effet
`Ctrl+D`	`Cmd+D`	sélectionner l'occurrence suivante du mot, pour éditer les deux à la fois
`Alt+↑` `Alt+↓`	`Opt+↑` `Opt+↓`	déplacer la ligne courante
`Shift+Alt+↓`	`Shift+Opt+↓`	dupliquer la ligne
`Ctrl+/`	`Cmd+/`	commenter ou décommenter la sélection
`F2`	`F2`	renommer un symbole partout où il apparaît
`Shift+Alt+F`	`Shift+Opt+F`	formater le fichier
`Ctrl+Shift+K`	`Cmd+Shift+K`	supprimer la ligne
`Ctrl+G`	`Ctrl+G`	aller à un numéro de ligne

Il n'est pas utile de les apprendre tous d'un coup. Prends-en un par semaine, celui qui correspond au geste que tu viens de faire trois fois à la souris.

Les raccourcis dépendent du clavier, pas seulement du système

Sur un clavier français, le terminal intégré s'ouvre avec Ctrl+ù et non avec l'accent grave indiqué dans la documentation anglophone. De même, Ctrl+/ demande souvent Ctrl+Shift+: selon la disposition.
La parade est toujours la même : ouvrir la palette, taper le nom de la commande, et lire le raccourci que l'éditeur affiche à droite. C'est la source de vérité pour ta configuration.

Ce que fait la recherche floue

Taper chmo dans Ctrl+P propose chargement_modele.py. La recherche ne demande ni un préfixe ni une sous-chaîne : elle demande que les lettres tapées apparaissent dans l'ordre, éventuellement séparées. Puis elle classe les résultats, sinon la liste serait inutilisable.

Le classement est la partie intéressante. Il faut favoriser les lettres consécutives et les débuts de mots, et surtout considérer tous les alignements possibles : prendre gloutonnement la première lettre venue place le m de chargement là où le bon alignement le mettrait sur modele, et le fichier attendu se retrouve en queue de liste.

main.py

Sortie

>_ Prêt à exécuter…

Le fichier visé arrive en tête, son test juste derrière, et machine/moteur.py ferme la marche : les lettres y sont, mais mal placées. Changez le motif pour test ou moteur et regardez l'ordre bouger.

Le serveur de langage

Définition

Un serveur de langage est un programme séparé qui analyse le code d'un langage donné et répond aux questions de l'éditeur : complétion, type d'une expression, définition d'un symbole, erreurs. L'échange suit un protocole commun, le LSP.

L'intérêt de cette séparation est économique. Avant, chaque éditeur réimplémentait l'analyse de chaque langage, soit un travail proportionnel au produit des deux nombres. Avec un protocole commun, un serveur écrit une fois sert tous les éditeurs.

Conséquence concrète : la qualité de la complétion ne dépend pas de l'éditeur mais de l'extension installée, et un serveur de langage a besoin de comprendre votre projet. S'il ne trouve pas l'environnement Python ou les dépendances, il signale des erreurs sur du code parfaitement valide. Le réflexe est alors de vérifier l'interpréteur sélectionné, pas de désinstaller l'extension.

Ce qu'un éditeur ne peut pas savoir

Il analyse le code sans l'exécuter. Il ignore donc ce qui ne se décide qu'à l'exécution : le contenu réel d'un fichier, la valeur d'une variable d'environnement, le type d'un objet construit dynamiquement.
Un code sans soulignement rouge n'est pas un code qui marche. Seule l'exécution le dit, et c'est le rôle des tests.

Les gestes qui changent le rapport au code

Quatre fonctions valent qu'on s'y arrête, parce qu'elles remplacent des manipulations risquées.

Renommer un symbole (F2) modifie la déclaration et toutes ses utilisations, en s'appuyant sur l'analyse du langage. Un chercher-remplacer sur la chaîne aurait aussi renommé les occurrences dans les commentaires, les chaînes de caractères, et une variable homonyme d'un autre fichier.

Le curseur multiple (Alt+clic, ou Ctrl+D pour ajouter l'occurrence suivante) permet la même édition à plusieurs endroits. Utile pour une transformation régulière que le renommage ne couvre pas.

Le formatage automatique applique un style unique. Le débat sur l'emplacement des accolades s'arrête le jour où plus personne ne les place à la main.

Le pliage et le fil d'Ariane aident dans un fichier long, mais un fichier qui a besoin d'être plié pour rester lisible demande surtout à être découpé.

Partager des réglages, ou pas

Un projet a des réglages qui le concernent, et chacun a des réglages qui ne concernent que lui. La distinction se matérialise par les fichiers versionnés.

Fichier	Contenu	Versionné
`.editorconfig`	indentation, fin de ligne, encodage, pour tout éditeur	oui
`.vscode/settings.json`	réglages du projet propres à VS Code	oui, en les gardant minimaux
`.vscode/extensions.json`	extensions recommandées à qui ouvre le projet	oui
réglages utilisateur	thème, police, raccourcis	non, ils vous appartiennent

# .editorconfig : compris par la plupart des éditeurs
root = true

[*]
indent_style = space
indent_size = 4
end_of_line = lf
charset = utf-8
insert_final_newline = true
trim_trailing_whitespace = true

Le formatage automatique sur un projet qui n'en avait pas

Activer « formater à l'enregistrement » sur un projet dont le code n'a jamais été formaté produit, au premier fichier touché, un diff de quatre cents lignes dont trois pour la correction réelle. La relecture devient impossible, et l'historique ne dit plus qui a écrit quoi.
La règle est de formater tout le projet d'un coup, dans un commit unique qui ne fait que cela, puis d'activer l'automatisme pour tout le monde. Le sujet revient au chapitre sur les tests et l'automatisation.

Le terminal intégré

L'éditeur embarque un terminal, ouvert dans le dossier du projet. Ce n'est pas un gadget : il évite de gérer deux fenêtres et surtout deux dossiers courants, source classique de confusion. Les commandes des chapitres précédents s'y utilisent à l'identique.

Reste une limite qui vaut d'être connue. Le terminal de l'éditeur hérite des variables d'environnement du processus qui a démarré l'éditeur. Si vous modifiez votre PATH puis lancez une commande dans ce terminal sans redémarrer l'éditeur, la modification peut ne pas être prise en compte.

Exercices type

Pourquoi ouvrir le dossier du projet plutôt que le fichier sur lequel on travaille ?

Parce que presque tout ce que l'éditeur apporte suppose le contexte.

La complétion sur vos propres fonctions demande de connaître les autres fichiers. Le saut vers une définition aussi. La recherche globale ne peut pas porter sur un projet dont l'outil ignore l'étendue. L'intégration Git a besoin de trouver le .git. Le serveur de langage a besoin du fichier de dépendances pour savoir quelles bibliothèques sont disponibles.

Sur un fichier seul, il reste la coloration syntaxique.

L'éditeur souligne en rouge un import parfaitement valide. Que faire ?

Ne pas toucher au code, qui n'est pas en cause.

Vérifier d'abord quel interpréteur ou quel environnement l'extension utilise : s'il ne s'agit pas de celui du projet, la bibliothèque installée est invisible pour lui.

Vérifier ensuite que la racine ouverte est bien celle du projet, sinon les chemins d'import ne se résolvent pas.

Le test décisif est d'exécuter le programme dans le terminal. S'il tourne, le problème est dans la configuration de l'éditeur, pas dans le code.

Quelle différence entre renommer par F2 et par un chercher-remplacer ?

Le chercher-remplacer travaille sur du texte. Il remplace toutes les occurrences de la chaîne, y compris dans les commentaires, dans les chaînes de caractères, et dans des variables homonymes qui n'ont rien à voir.

F2 travaille sur le symbole, tel que l'analyse du langage l'a identifié. Il ne touche que la déclaration et ses références réelles, en respectant la portée.

Sur une variable nommée x ou data, la différence est celle qui sépare une modification correcte d'un projet cassé.

Faut-il versionner le dossier .vscode ?

En partie.

Ce qui concerne le projet se versionne : le chemin de l'interpréteur relatif au projet, le formateur retenu, la liste des extensions recommandées, la configuration de lancement du débogueur. Ces réglages font gagner du temps à qui arrive sur le projet.

Ce qui concerne la personne ne se versionne pas : thème, taille de police, raccourcis, chemins absolus propres à une machine.

Le critère est simple : un réglage que vous seriez gêné d'imposer à un collègue n'a rien à faire dans le dépôt.

Une extension propose de corriger automatiquement tout le fichier à l'enregistrement. Bonne idée ?

Oui pour un projet qui a déjà un style unifié et une convention partagée. C'est même le meilleur moyen de ne plus jamais discuter de mise en forme.

Non si vous êtes seul à l'activer sur un projet qui n'est pas formaté : chacun de vos commits mélangera alors le vrai changement et une réécriture massive du fichier, et la relecture deviendra impossible.

La bonne séquence est de décider en équipe, de formater tout le projet en un commit dédié, puis d'automatiser.

La méthode

Ouvre la racine du projet, celle qui contient le .git et le fichier de dépendances.
Apprends trois raccourcis avant tous les autres : fichier, palette, recherche globale.
Passe par la palette quand tu ne sais pas où se trouve une commande, plutôt que par les menus.
Renomme par la fonction dédiée, jamais par un chercher-remplacer.
Vérifie l'interpréteur sélectionné avant de croire un diagnostic de l'éditeur.
Versionne les réglages du projet, garde les tiens pour toi.
N'active pas de formatage automatique sur un projet qui n'a pas encore de style commun.

En résumé

Un éditeur de code connaît le langage ; un traitement de texte manipule des caractères.
Ouvrir le dossier du projet conditionne complétion, navigation et recherche.
La recherche de fichier accepte une sous-suite de lettres, puis classe les résultats.
Un serveur de langage est un programme séparé, partagé entre éditeurs par un protocole commun.
L'analyse est statique : l'absence d'erreur signalée ne prouve pas que le programme fonctionne.
Renommer est une opération sur un symbole, pas sur une chaîne de caractères.
Les réglages du projet se versionnent, ceux de la personne restent locaux.
Le formatage automatique ne se met en place qu'après un formatage global assumé.

Et ensuite ? L'éditeur sait où est définie une fonction. Il ne sait pas pourquoi elle renvoie une mauvaise valeur. Le chapitre suivant s'occupe de cette question : déboguer.

Ce que ce chapitre apporte