Repérer une coquille dans une config
API_TIMEOUT=3000API_TIMEOUT=30000Un zéro de trop transforme un timeout de 3 secondes en 30 secondes. Le diff checker le voit en une seconde — comparer deux fichiers .env à l'œil, on passe souvent à côté.
Comparez deux blocs de texte ou de code côte à côte par ligne et par mot.
Dernière mise à jour
function greet(name) {+function greet(name) { console.log("Hello, " + name);+ console.log(`Hello, ${name}!`);return name;+
return name.toUpperCase();
}+
}
greet("world");+greet("World");Un diff checker compare deux morceaux de texte ou de code et met en évidence ce qui a été ajouté, supprimé ou modifié. Les développeurs s'en servent en permanence : revue de code, debug d'un changement de configuration, comparaison de réponses d'API, vérification d'une migration, ou tout simplement relecture d'une modif avant de la commiter.
Savoir lire un diff fait partie des compétences de base du métier. C'est ce qui permet de distinguer *un vrai changement de comportement* d'un simple reformatage anodin, et de repérer le seul caractère modifié au milieu de 200 lignes. Une fois que le rythme vert / rouge / jaune devient automatique, la revue de code va beaucoup plus vite.
Deux types de diff comptent vraiment : le *diff par ligne* (quelles lignes ont changé) et le *diff par mot* ou *par caractère* (ce qui a changé à l'intérieur d'une ligne). Un bon outil permet de basculer de l'un à l'autre selon que vous comparez du code source ou de la prose.
Mettez l'original à gauche et la nouvelle version à droite. Code, JSON, prose, fichier de config — tout marche.
Diff par ligne pour le code source ou les données structurées. Diff par mot pour comparer des paragraphes où c'est la formulation qui compte.
Activez *ignorer les espaces* si seuls les vrais changements vous intéressent, et *ignorer la casse* pour comparer des logs ou du texte où les majuscules/minuscules sont sans importance.
Le contenu supprimé apparaît en rouge à gauche, le contenu ajouté en vert à droite. Une ligne modifiée apparaît souvent comme une rouge et une verte côte à côte.
Modifiez l'un ou l'autre côté et le diff se met à jour en direct. Pratique pour préparer un patch propre avant d'ouvrir une pull request.
Conventions utilisées par le diff checker de Coddy — et qu'on retrouve dans git diff, GitHub et la plupart des autres visualiseurs de diff.
| Marqueur | Signification | Où ça apparaît |
|---|---|---|
Rouge / - | Ligne supprimée par rapport à l'original | Volet de gauche |
Vert / + | Ligne ajoutée dans la nouvelle version | Volet de droite |
| Jaune / les deux | Ligne modifiée — changement partiel à l'intérieur de la ligne | Les deux volets |
| Sans couleur | Ligne inchangée — identique dans les deux versions | Les deux volets |
@@ ... @@ | En-tête de hunk dans git diff — numéros de lignes | Sortie git diff en terminal |
| Diff par mot | Changement au niveau du mot ou du caractère dans une ligne modifiée | Surligné à l'intérieur d'une ligne jaune |
API_TIMEOUT=3000API_TIMEOUT=30000Un zéro de trop transforme un timeout de 3 secondes en 30 secondes. Le diff checker le voit en une seconde — comparer deux fichiers .env à l'œil, on passe souvent à côté.
L'utilisateur peut se connecter au serveur.
L'utilisateur peut se déconnecter du serveur.
Le diff par mot met en évidence connecter → déconnecter et au → du. Un diff par ligne afficherait simplement la ligne entière comme modifiée ; le diff par mot isole la vraie modif.
{ "id": 42, "status": "draft", "published": false}{ "id": 42, "status": "published", "published": true}Le diff montre tout de suite que deux champs liés ont changé en même temps. C'est la façon la plus rapide de vérifier qu'un appel d'API qui modifie un état a bien fait ce qu'il devait faire.
git diff, les vues de pull request et les comparateurs intégrés aux IDE reposent tous sur la même idée.