NSI · Terminale · Génie logiciel
Bonnes pratiques logicielles
Écrire pour celui qui relira.
En bref
Le coût d’un programme se joue moins à l’écriture qu’à la relecture et à la modification.
Le coût d’un programme se joue moins à l’écriture qu’à la relecture et à la modification. Les bonnes pratiques ne sont pas des règles de politesse : ce sont des économies mesurables.
Nommer
Un nom doit dire ce que la chose est, pas ce qu’elle vaut ni comment elle est faite.
| Nom | Ce qu’il exige |
|---|---|
| nb_eleves_inscrits | Aucun commentaire |
| x | Un commentaire, forcément |
La règle : plus la portée est large, plus le nom doit être explicite. Un compteur de boucle courte peut s’appeler i.
Commenter
| Commentaire | Son verdict |
|---|---|
| « incrémente i » | Inutile : il répète le code |
| « on saute le premier enregistrement, qui est l’en-tête » | Indispensable : il explique le pourquoi |
Un commentaire faux est pire que pas de commentaire : il induit en erreur celui qui lui fait confiance.
Les deux règles de structure
| Règle | Ce qu’elle évite |
|---|---|
| Pas de duplication | Deux morceaux identiques évolueront séparément : on corrigera un bug dans l’un et pas dans l’autre |
| Fonctions courtes | Une fonction fait une seule chose. Si son nom contient « et », elle en fait deux |
Les tests
Un test unitaire vérifie une fonction isolée sur des cas choisis.
| Cas à couvrir | Exemples |
|---|---|
| Le cas nominal | L’usage attendu |
| Les cas limites | Liste vide, un seul élément, valeur nulle, borne exacte |
| Les cas d’erreur | Entrée invalide |
Dijkstra : les tests montrent la présence de bugs, jamais leur absence. Un test réussi prouve seulement qu’on n’échoue pas sur les cas testés.
Les tests servent aussi de filet : ils permettent de modifier le code sans crainte, ce qui rend la refactorisation possible.
La gestion de versions
git enregistre l’historique, permet de revenir en arrière, de travailler à plusieurs sur le même fichier et de retrouver quand et pourquoi une ligne a changé.
Chaque enregistrement doit être petit et porter un message qui explique l’intention.
La spécification
Avant d’écrire, il faut savoir ce que le programme doit faire — et ce qu’il ne doit pas faire.
Un programme conforme à une mauvaise spécification est un programme raté, même sans aucun bug.
La question avant de valider une modification : « quelqu’un qui découvre ce fichier comprendra-t-il en une minute ce qu’il fait ? » Si non, ce n’est pas fini.
Teste-toi
6 questions pour vérifier
Touche une réponse : la correction s’affiche tout de suite.
1.Que doit expliquer un bon commentaire ?
2.Que prouve un test unitaire réussi ?
3.Quels cas un jeu de tests doit-il couvrir ?
4.Pourquoi la duplication de code est-elle un problème ?
5.À quoi sert un système de gestion de versions comme git ?
6.Les tests rendent la refactorisation possible.
0 / 6 questions
Dans l’app, ce chapitre a son quiz complet, chronométré, et tes erreurs reviennent au bon moment pour ne plus les refaire.
La fiche de révision, sur une page
Tout « Bonnes pratiques » sur une seule page A4 illustrée : l’essentiel, les pièges et un mini-test. Elle se débloque dans l’app avec des gemmes — et ton compte gratuit en offre assez pour tes trois premières fiches.
