$course$/QCM de NSI/Première/Spécification Spécifier une fonction : signature (nom, paramètres,
type de retour), préconditions, postconditions,
documentation par docstrings, exemples d'usage,
relation avec les tests.

]]> Spécification — Q01 : Spécification Qu'est-ce que la spécification d'une
fonction ?

]]> Adage : « bien spécifier = à moitié
implémenté ». Bien spécifier permet de
tester, de documenter, et de coder
correctement.

]]> 1.0 0.0 0 true true abc Sa vitesse d'exécution sur la machine

]]> La vitesse d'exécution est
une mesure de performance,
observable à l'usage. Ce
n'est pas la
spécification, qui décrit
le comportement attendu
de la fonction.

]]> Son code source complet, recopié intégralement ligne par ligne

]]> Le code source décrit
comment la fonction
réalise sa tâche, alors
que la spécification
décrit ce qu'elle doit faire. Les deux
notions sont
distinctes.

]]> Son nombre total de lignes de code

]]> Le nombre de lignes est
une mesure du code, sans
rapport avec ce que la
fonction est censée
accomplir.

]]> Ce que la fonction doit faire, indépendamment du code

]]> Bonne réponse : la spécification est un
contrat entre l'auteur et
l'utilisateur. Elle précède
l'implémentation.

]]> Spécification — Q02 : Signature Qu'appelle-t-on la signature d'une fonction ?

]]> Deux fonctions de même signature sont
interchangeables du point de vue de
l'appelant. C'est la base de la modularité.

]]> 1.0 0.0 0 true true abc Le numéro de ligne où la fonction est définie dans le fichier

]]> La position dans le
fichier source ne fait
pas partie de la
signature : seuls le
nom, les paramètres et
le type de retour la
composent.

]]> Son nom, ses paramètres typés et son type de retour

]]> Bonne réponse : c'est l'« en-tête »
identifiant uniquement la fonction. En
Python avec annotations :
def carre(x: int) -> int:.

]]> La date de création

]]> La date de création n'a
aucun lien avec la
signature, qui désigne
uniquement l'en-tête
identifiant la
fonction.

]]> Le nom de l'auteur de la fonction

]]> Cette interprétation
littérale n'a aucun
rapport avec le sens
technique du mot
« signature » en
programmation.

]]> Spécification — Q03 : Précondition Qu'est-ce qu'une précondition ?

]]> C'est l'utilisateur qui doit garantir la
précondition. La fonction peut faire
confiance à ses paramètres (sauf si elle
est défensive et vérifie elle-même).

]]> 1.0 0.0 0 true true abc Une condition tirée au hasard

]]> Une précondition n'a rien
d'aléatoire. C'est une
contrainte explicite,
documentée par le
concepteur de la
fonction.

]]> Une condition vérifiée juste après l'appel de la fonction

]]> Erreur : ce serait une postcondition.

]]> Une condition vraie avant l'appel, sur les paramètres

]]> Bonne réponse : par exemple, pour une
fonction racine(x), la précondition
peut être « x ≥ 0 ». Si la précondition
n'est pas respectée, la fonction n'a
pas à fonctionner correctement.

]]> Une condition d'arrêt d'une boucle du programme

]]> La condition d'arrêt
d'une boucle est une
notion liée au contrôle
de flux d'un programme,
et non à la
spécification d'une
fonction.

]]> Spécification — Q04 : Postcondition Qu'est-ce qu'une postcondition ?

]]> Précondition + postcondition = contrat
de la fonction. Cette approche est dite
« programmation par contrat ».

]]> 1.0 0.0 0 true true abc Le type de retour déclaré dans la signature de la fonction

]]> Le type de retour fait
partie de la signature.
La postcondition est, elle,
une propriété logique
que la valeur renvoyée
doit vérifier (par
exemple, « le résultat
est positif »).

]]> Une condition tirée au hasard

]]> Une postcondition n'a
rien d'aléatoire. C'est
une garantie explicite
fournie par la fonction
sur son résultat.

]]> Ce que la fonction garantit sur son résultat en sortie

]]> Bonne réponse : par exemple, pour
racine(x), la postcondition est
« la valeur renvoyée r vérifie
r * r == x » (à epsilon près pour les
flottants).

]]> Une condition avant l'appel

]]> Erreur : ce serait une précondition.

]]> Spécification — Q05 : Docstring Comment documenter une fonction Python selon la convention du langage ?

]]> Docstring de qualité : description courte,
ligne vide, description détaillée,
paramètres, retour, exemples (>>> ...).

]]> 1.0 0.0 0 true true abc Dans un fichier README placé à part

]]> La documentation
générale d'un projet
peut être placée dans un
fichier README, mais la
documentation d'une
fonction se met
directement dans son
corps, à l'aide d'une
docstring.

]]> Avec un commentaire placé tout à la fin de la fonction

]]> Erreur : la convention est de placer la documentation en tout début de corps de fonction, sous forme de docstring, juste après la ligne def.

]]> Avec un commentaire # au-dessus

]]> Erreur : un commentaire # se lit dans le code, mais la convention de Python pour documenter une fonction est la docstring, placée dans le corps de la fonction.

]]> Avec une docstring en première instruction du corps

]]> Bonne réponse : def f(x): puis, sur la ligne suivante, """description...""". C'est ce texte qu'affiche help(f).

]]> Spécification — Q06 : Exemple complet Quelle est la bonne pratique pour spécifier
une fonction Python valeur_absolue(x) ?

]]> Bonnes pratiques : signature typée,
docstring claire, contrat
pré-/post-conditions documenté.

]]> 1.0 0.0 0 true true abc ``python
def valeur_absolue(x: float) -> float:
"""Renvoie la valeur absolue de x.

Précondition : x est un nombre.
Postcondition : le résultat est >= 0.
"""
return abs(x)
``

]]> Bonne réponse : signature avec types,
docstring décrivant le but, pré- et
postconditions. Le code se documente
lui-même.

]]> `python
def valeur_absolue(x):
"""valeur_absolue(x)"""
return abs(x)
`

]]> Erreur : la docstring ne fait que répéter
le nom de la fonction. Elle ne dit ni ce
que fait la fonction, ni ce qu'elle attend,
ni ce qu'elle garantit.

]]> `python
# x est un nombre
# renvoie sa valeur absolue
def valeur_absolue(x):
return abs(x)
`

]]> Erreur : la spécification est écrite en commentaires placés au-dessus de la fonction. Elle est lisible, mais la convention de Python est une docstring, chaîne entre triples guillemets placée sous la signature.

]]> `python
def valeur_absolue(x: float) -> float:
# Renvoie la valeur absolue de x.
# Précondition : x est un nombre.
return abs(x)
`

]]> Erreur : la spécification est écrite en commentaires dans le corps. La forme attendue est une docstring, chaîne entre triples guillemets placée sous la signature.

]]> Spécification — Q07 : Pourquoi spécifier ? Pourquoi spécifier une fonction avant de
l'écrire ?

]]> Sans spécification : code parfois
« qui marche », mais buggé sur des cas
limites non envisagés. Avec spécification :
cas limites pensés en amont.

]]> 1.0 0.0 0 true true abc Pour ralentir l'exécution du code

]]> La spécification n'a
aucune incidence sur la
performance ; elle
précède l'écriture du
code et ne s'exécute
pas.

]]> Pour utiliser davantage de mémoire

]]> La spécification est un
document conceptuel
rédigé avant le code.
Elle n'a aucun rapport
avec la consommation
mémoire à l'exécution.

]]> Parce que c'est strictement obligatoire dans le langage Python

]]> Erreur : ce n'est pas une obligation
syntaxique. C'est une bonne pratique.

]]> Pour clarifier le but, faciliter les tests et la documentation

]]> Bonne réponse : la spécification
structure la pensée. On évite de coder
dans le brouillard. La fonction est
alors testable.

]]> Spécification — Q09 : Écrire un test avec assert La fonction carre(x) doit renvoyer le carré de x. Quelle ligne constitue un test qui arrête le programme si carre(3) ne renvoie pas 9 ?

]]> Un test compare le résultat d'un appel à la valeur attendue par la spécification. Écrit avec assert, il ne dit rien quand tout va bien et arrête le programme dès qu'un résultat est faux.

]]> 1.0 0.0 0 true true abc assert carre(3) == 9

]]> Bonne réponse : si la comparaison est fausse, assert arrête le programme avec une AssertionError ; si elle est vraie, l'exécution continue sans rien afficher.

]]> assert carre(3) = 9

]]> Erreur : le signe = sert à l'affectation. Cette ligne provoque une erreur de syntaxe ; une comparaison s'écrit avec ==.

]]> carre(3) == 9

]]> Erreur : cette ligne calcule un booléen, mais personne ne l'exploite. Si carre(3) renvoyait une autre valeur, le programme continuerait sans rien signaler.

]]> assert carre(9) == 3

]]> Erreur : les rôles sont inversés. Pour une fonction correcte, carre(9) vaut 81 : ce test arrêterait le programme alors que la fonction est juste.

]]> Spécification — Q10 : Cas limites Quels sont les cas limites typiques à
considérer en spécifiant une fonction sur une
liste ?

]]> Pour les nombres : 0, négatifs, très
grands, fractionnaires. Pour les chaînes :
vide, un caractère, accents, emojis. Pour
les listes : vide, un élément, doublons,
triée/non triée.

]]> 1.0 0.0 0 true true abc Une liste constituée uniquement d'éléments imaginaires

]]> Cette interprétation
n'a pas de sens en
informatique : on
travaille toujours avec
des données concrètes.

]]> Liste vide, à un élément, ou très longue

]]> Bonne réponse : ces cas révèlent
souvent des bugs. Toujours les inclure
dans les tests.

]]> Aucun, le cas général suffit

]]> Erreur : les bugs sont souvent dans les
cas limites.

]]> Une liste de couleurs

]]> Cette description est
trop spécifique : on
cherche ici les cas
limites génériques d'une
fonction sur une
liste, indépendamment
du type de ses
éléments.

]]> Spécification — Q12 : Identifier la précondition Pour la fonction
`python
def diviser(a, b):
return a / b
`
Quelle est une précondition essentielle ?

]]> Bonnes pratiques : (1) noter la
précondition dans la docstring ; (2) la
vérifier en début de fonction avec
assert ; (3) la tester explicitement.

]]> 1.0 0.0 0 true true abc a == b

]]> L'égalité entre a et
b ne joue aucun rôle
dans la division. Cette
contrainte n'est pas
une précondition
pertinente.

]]> b != 0

]]> Bonne réponse : sans cette
précondition, on lève
ZeroDivisionError. À documenter
clairement.

]]> a > 0

]]> La division est
parfaitement définie
pour toute valeur de
a (positive, nulle ou
négative). Cette
contrainte n'est donc
pas une précondition
nécessaire.

]]> Aucune précondition n'est nécessaire

]]> Une précondition est
bien nécessaire :
b != 0, faute de quoi
la division provoque
une exception.

]]> Spécification — Q13 : Bonne docstring Que devrait contenir une bonne docstring ?

]]> Une docstring minimale décrit le but, les paramètres et la valeur renvoyée ; une docstring complète y ajoute des exemples d'appel et des remarques sur les cas particuliers.

]]> 1.0 0.0 0 true true abc Un poème ou un texte décoratif

]]> Cette interprétation est
fantaisiste. La
docstring doit être
claire, factuelle et
informative.

]]> Le but, les paramètres, la valeur renvoyée et des exemples

]]> Bonne réponse : ce sont les informations utiles à l'utilisateur, qui peut ainsi appeler la fonction sans avoir besoin de lire son code.

]]> Uniquement le nom de l'auteur ayant rédigé la fonction et sa date

]]> Le nom de l'auteur peut
y figurer en complément,
mais il ne suffit pas :
la docstring sert avant
tout à décrire le
comportement de la
fonction.

]]> Le code source intégral de la fonction

]]> La docstring décrit le
comportement de la
fonction. Reproduire
son code source serait
redondant : ce dernier
est déjà visible juste
après.

]]> Spécification — Q14 : help() Que fait help(ma_fonction) en Python ?

]]> help() est un raccourci interactif pour consulter la documentation d'une fonction ou d'une bibliothèque. Toujours documenter ses fonctions, pour aider les futurs lecteurs, y compris soi-même.

]]> 1.0 0.0 0 true true abc Affiche la signature et la docstring de la fonction

]]> Bonne réponse : c'est pourquoi documenter une fonction par une docstring est utile, la documentation s'affiche directement dans l'interpréteur.

]]> Elle lance la documentation officielle en ligne sur Internet

]]> Erreur : help ne consulte aucune ressource en ligne. Elle affiche la documentation disponible sur place, fournie par la docstring de la fonction.

]]> Elle exécute la fonction donnée en argument

]]> La fonction help se
contente d'afficher la
documentation associée
à son argument ; elle
n'exécute pas la
fonction.

]]> Renvoie le code source

]]> Erreur : help affiche la signature et la docstring de la fonction, pas les instructions de son corps.

]]> Spécification — Q15 : Protéger une fonction par une assertion La fonction racine(x) a pour précondition x >= 0. Quelle ligne, placée au début de son corps, arrête le programme dès qu'un appel ne respecte pas cette précondition ?

]]> `python
def racine(x):
assert x >= 0, "x doit être positif ou nul"
return x ** 0.5
`
Une assertion en tête de fonction vérifie la précondition à chaque appel. Le message qui la suit aide à comprendre l'arrêt.

]]> 1.0 0.0 0 true true abc # précondition : x >= 0

]]> Erreur : un commentaire documente la précondition mais Python l'ignore. Un appel racine(-4) s'exécuterait sans aucun signalement.

]]> assert x >= 0

]]> Bonne réponse : si x est négatif, l'assertion est fausse et le programme s'arrête avec une AssertionError, avant tout calcul absurde.

]]> return x >= 0

]]> Erreur : return termine la fonction et renvoie un booléen, à chaque appel. La racine ne serait jamais calculée, et aucun appel incorrect ne serait signalé.

]]> assert x < 0

]]> Erreur : la condition est inversée. Une assertion énonce ce qui doit être vrai ; celle-ci arrêterait le programme pour tous les appels corrects et laisserait passer les mauvais.

]]> Spécification — Q16 : Type de retour Pourquoi spécifier le type de retour d'une
fonction ?

]]> Annotations de type courantes : int, float, str, bool, list, dict. Elles documentent le prototype de la fonction sans rien changer à son exécution.

]]> 1.0 0.0 0 true true abc C'est obligatoire en Python

]]> L'annotation du type de
retour est facultative
en Python ; le langage
accepte parfaitement les
fonctions sans
annotation.

]]> Cela rend la fonction nettement plus rapide à l'exécution

]]> Les annotations de type
n'ont aucun effet sur la
performance d'exécution
en Python : elles ne
servent qu'à
documenter.

]]> Pour clarifier ce que reçoit l'appelant

]]> Bonne réponse : par exemple, def moyenne(notes: list) -> float annonce à l'appelant qu'il recevra un flottant, sans qu'il ait à lire le corps de la fonction.

]]> Pour économiser de la mémoire à l'exécution

]]> Les annotations de type
n'ont aucun effet sur
la consommation mémoire
d'un programme Python.

]]> Spécification — Q17 : Bonne signature Quelle signature est la plus claire pour
« calculer la moyenne d'une liste de notes » ?

]]> Bonnes pratiques de nommage : verbes pour
les fonctions (« calculer », « afficher »,
« valider »), noms explicites pour les
paramètres (notes plutôt que l).

]]> 1.0 0.0 0 true true abc def moyenne(notes: list[float]) -> float:

]]> Bonne réponse : nom explicite, type du
paramètre, type de retour. Le lecteur
comprend tout sans lire le code.

]]> def moyenne_liste_notes_float(x):

]]> Erreur : le nom entasse des informations
qui devraient être portées par les
annotations, et le paramètre x ne dit
rien de ce qu'il reçoit.

]]> def moyenne(notes: list[float]) -> str:

]]> Erreur : le nom et le paramètre sont clairs,
mais l'annotation de retour str est
fausse, une moyenne est un nombre. Une
annotation erronée est pire qu'une absence
d'annotation.

]]> def moyenne(notes: list[float], n: int) -> float:

]]> Erreur : le paramètre n est redondant, la
longueur de la liste s'obtient par
len(notes). Un paramètre superflu rend la
signature ambiguë : que faire si n ne vaut
pas len(notes) ?

]]> Spécification — Q18 : Cas particuliers Pour la fonction moyenne(notes), quel cas limite poserait problème ?

]]> Toujours penser : que se passe-t-il si
l'entrée est vide / unique / extrême ?
C'est typiquement là que se cachent les
bugs.

]]> 1.0 0.0 0 true true abc Une note décimale, par exemple 12{,}5 ou 14{,}25

]]> Les notes à virgule ne
posent pas de problème
particulier au calcul
de la moyenne.

]]> La liste vide, qui divise par zéro

]]> Bonne réponse : sum([]) / len([]) =
0 / 0 → ZeroDivisionError. À
décider : précondition « liste non
vide », ou retour spécial (None,
nan).

]]> Une note négative

]]> Une note négative n'a
rien d'un cas limite sur
le plan mathématique :
elle ne pose aucun
problème de calcul.

]]> Une liste de cent notes

]]> Une liste contenant cent
notes constitue un cas
tout à fait standard,
sans difficulté
particulière.

]]> Spécification — Q19 : Spec et robustesse Comment une bonne spécification améliore-t-elle
la robustesse d'un programme ?

]]> Citation : « Si vous ne pouvez pas
spécifier ce que doit faire votre code,
vous ne savez pas ce qu'il doit faire. »
Conséquence directe : difficile à coder,
tester, déboguer.

]]> 1.0 0.0 0 true true abc En faisant réfléchir aux cas limites et aux entrées valides

]]> Bonne réponse : la rigueur de la
spécification se reflète dans la
qualité du code. Et permet de tester
systématiquement.

]]> En réduisant le nombre de lignes

]]> Le nombre de lignes
dépend du style et des
contraintes du langage,
pas de la spécification.
Une bonne spec apporte
de la rigueur, pas de
la concision.

]]> En écrivant le code plus rapidement

]]> Pas garanti.

]]> En obligeant à utiliser partout des types statiques très forts

]]> Pas spécifiquement.

]]> Spécification — Q20 : Choisir un jeu de tests La spécification de tarif(age) indique : « renvoie 5 si age est strictement inférieur à 18, et 8 sinon ». Quel jeu de tests vérifie le mieux cette spécification ?

]]> Un bon jeu de tests couvre chaque cas de la spécification et ses frontières, avec des valeurs attendues conformes au texte. Même ainsi, le succès d'un jeu de tests ne garantit pas la correction du programme.

]]> 1.0 0.0 0 true true abc tarif(30) == 8, tarif(50) == 8, tarif(70) == 8

]]> Erreur : aucun test ne porte sur les moins de 18 ans. Une fonction qui renverrait toujours 8 passerait ce jeu de tests sans encombre.

]]> tarif(10) == 5, tarif(18) == 5, tarif(40) == 8

]]> Erreur : le test tarif(18) == 5 contredit la spécification, puisque 18 n'est pas strictement inférieur à 18. Une fonction correcte échouerait à ce test.

]]> tarif(17) == 5, tarif(18) == 8, tarif(40) == 8

]]> Bonne réponse : les deux cas de la spécification sont testés, ainsi que la frontière entre eux, 17 et 18, où se glissent les erreurs du type <= au lieu de <.

]]> tarif(10) == 5, tarif(12) == 5, tarif(15) == 5

]]> Erreur : les trois tests portent sur le même cas, celui des moins de 18 ans. Une fonction qui renverrait toujours 5 les réussirait tous.

]]> Spécification — Q21 : Spécification ambiguë Quel problème a la spécification suivante ?
« La fonction chercher(liste, valeur) cherche
la valeur dans la liste. »

]]> Signe d'une bonne spec : un autre
développeur peut implémenter la fonction
sans poser de question et son code
passe les tests fournis.

]]> 1.0 0.0 0 true true abc Aucun problème, cette spécification est parfaitement claire et complète

]]> Erreur : trop ambiguë.

]]> Trop d'ambiguïtés sur ce qu'il faut renvoyer selon les cas

]]> Bonne réponse : une bonne spec doit
lever toutes les ambiguïtés. Sinon,
deux développeurs feront deux
implémentations différentes,
incompatibles.

]]> La fonction n'a pas assez de paramètres

]]> La signature chercher(liste,
valeur) est cohérente :
deux paramètres suffisent
pour décrire la recherche.
Le défaut de cette spec
tient à l'imprécision de
l'énoncé, pas au nombre
de paramètres.

]]> Le nom de la fonction est trop long

]]> Pas le problème.

]]> Spécification — Q22 : Cas d'erreur Comment doit-on spécifier le comportement en cas d'erreur d'une fonction ?

]]> Trois écoles : Python privilégie les
exceptions, comme l'erreur ValueError
que provoque int("abc") ; C/Go préfèrent
les codes de retour ; certains langages
forcent des types Result/Option (Rust).

]]> 1.0 0.0 0 true true abc Laisser le programme planter brutalement, sans rien prévoir de précis

]]> Possible (exception non rattrapée),
mais à documenter.

]]> Renvoyer aléatoirement

]]> Un comportement aléatoire
en cas d'erreur rendrait
la fonction imprévisible
et inutilisable. Une bonne
spec définit toujours un
comportement déterministe :
valeur sentinelle, exception
ou précondition explicite.

]]> Décider explicitement : valeur spéciale, exception ou précondition

]]> Bonne réponse : trois stratégies
principales. À documenter. Une fois
choisie, être cohérent dans tout
le projet.

]]> Ne pas y penser

]]> Erreur classique : les bugs viennent
souvent de cas non spécifiés.

]]> Spécification — Q23 : Spec et évolution Pourquoi une spécification claire facilite-t-elle
la maintenance d'un programme ?

]]> Principe de boîte noire : la fonction
est opaque pour l'appelant. Sa spec est
l'interface, son implémentation reste
interne. C'est un pilier de la
programmation modulaire.

]]> 1.0 0.0 0 true true abc Parce qu'elle élimine totalement et définitivement les bugs

]]> Cette affirmation est
trop optimiste. La
spécification ne supprime
pas tous les bugs, mais
elle structure le
travail et facilite
leur détection.

]]> Parce que le code obtenu est plus court

]]> La longueur du code n'a
pas de lien direct avec
la qualité de la
spécification.

]]> On peut réécrire l'implémentation sans changer le contrat

]]> Bonne réponse : c'est l'abstraction.
Tant que la spec est respectée, le code
appelant n'est pas affecté. Permet
d'optimiser, refactoriser, corriger
sans cascade de changements.

]]> Parce qu'une spécification est jolie à lire

]]> L'esthétique d'un
document est un
critère subjectif. Ce
n'est pas l'argument
qui justifie l'intérêt
pratique d'une
spécification.

]]> Spécification — Q25 : Synthèse Parmi les affirmations suivantes sur la
spécification, laquelle est fausse ?

]]> Mnémonique : pré comme « avant »
(responsabilité de l'appelant), post
comme « après » (responsabilité de la
fonction).

]]> 1.0 0.0 0 true true abc La précondition est ce que la fonction doit garantir à l'appel

]]> Faux (donc bonne réponse) : la
précondition est une condition que
l'appelant doit garantir avant
l'appel. La fonction garantit la
postcondition en sortie.

]]> La signature comprend nom, paramètres et type de retour

]]> Vrai : définition standard.

]]> La docstring permet d'accéder à la documentation via help()

]]> Cette affirmation est correcte : la docstring placée en tête d'une fonction est affichée par help(). Ce n'est donc pas la mauvaise affirmation recherchée.

]]> Une bonne spécification facilite la maintenance et la robustesse

]]> Cette affirmation est
juste : une spécification
claire réduit les
ambiguïtés, simplifie la
maintenance et limite
les bogues. Ce n'est
donc pas la mauvaise
affirmation recherchée.

]]> Spécification — Q26 : Effet de bord vs valeur de retour Une fonction de tri peut être spécifiée de
deux façons différentes. Comment la
spécification doit-elle distinguer
explicitement ces deux choix ?

]]> Convention Python : un nom impératif comme
sort désigne souvent une modification en
place ; un nom au participe passé comme
sorted désigne une fonction pure qui
renvoie un nouvel objet. Toute
spécification doit préciser explicitement
ce point.

]]> 1.0 0.0 0 true true abc La spécification précise si la fonction modifie la liste ou en renvoie une copie triée

]]> Bonne réponse : c'est exactement la
distinction faite par Python entre
liste.sort() (en place, retourne None)
et sorted(liste) (renvoie une nouvelle
liste). La spécification doit toujours
préciser cela, sinon le comportement est
ambigu et bogué en pratique.

]]> La distinction est purement esthétique et n'a pas d'effet réel

]]> Erreur : la différence est
fondamentale. Modifier en place ou
renvoyer une copie n'a pas le même coût
mémoire, et expose à des erreurs
d'aliasage si plusieurs variables
référencent la même liste.

]]> La distinction se fait au moment de l'exécution, selon la mémoire disponible sur la machine

]]> Erreur : ce serait imprévisible et
rendrait le comportement non
reproductible. Une bonne spécification
fixe le comportement à l'avance, pas en
fonction de l'environnement.

]]> La distinction n'a pas d'importance, l'utilisateur s'adapte au comportement obtenu

]]> Erreur : c'est exactement l'origine de
nombreux bugs en pratique. Si la
spécification ne dit pas si la liste est
modifiée ou si une nouvelle liste est
renvoyée, l'utilisateur peut écrire
liste = trier(liste) alors que
trier modifie déjà liste (et renvoie
None), ce qui détruit la liste.

]]> Spécification — Q27 : Précondition, postcondition, invariant Dans une fonction qui parcourt une liste avec
une boucle, comment se distinguent
précondition, postcondition et
invariant de boucle ?

]]> Schéma général d'une preuve : précondition à
l'entrée → invariant initialement vrai →
invariant conservé à chaque itération → en
sortie de boucle, l'invariant combiné à la
condition d'arrêt entraîne la postcondition.
Les trois notions s'articulent et ne se
remplacent pas.

]]> 1.0 0.0 0 true true abc L'invariant de boucle remplace à lui seul la précondition et la postcondition de la fonction

]]> Erreur : les trois notions coexistent.
L'invariant de boucle est précisément
l'outil qui fait le pont entre
précondition et postcondition à
travers la boucle.

]]> La précondition est une postcondition imprécise

]]> Erreur : ces deux notions ne sont pas
comparables, elles ont un statut
symétrique. La précondition est garantie
par l'appelant, la postcondition par la
fonction.

]]> Ce sont trois noms différents pour la même notion

]]> Erreur : ces trois notions ne portent
pas sur la même chose. Elles concernent
respectivement l'entrée de la fonction,
sa sortie, et la boucle interne.

]]> La précondition porte sur l'entrée, la postcondition sur la sortie, l'invariant sur la boucle

]]> Bonne réponse : trois échelles
différentes. La précondition est le
contrat à l'entrée de la fonction, la
postcondition le contrat à la sortie, et
l'invariant de boucle un outil interne
qui sert à prouver la postcondition à
partir de la précondition.

]]> Spécification — Q28 : Tester une fonction que l'on croit juste Lina a relu sa fonction trois fois et la trouve correcte. Pourquoi
écrire quand même des tests ?

]]> Un test confronte la fonction à sa spécification sur des cas
choisis : c'est le moyen le plus sûr de détecter une erreur avant
les utilisateurs.

]]> 1.0 0.0 0 true true abc Parce que Python exige des tests pour exécuter une fonction

]]> Erreur : Python n'impose rien ; les tests sont une discipline du
programmeur.

]]> Parce qu'une relecture ne remplace pas une exécution

]]> Bonne réponse : les erreurs de frontière, d'indice ou de type
échappent souvent à la lecture. Un test exécute réellement la
fonction et compare le résultat à la spécification.

]]> Pour rendre la fonction plus rapide à l'exécution

]]> Erreur : tester ne change pas la fonction, cela la vérifie.

]]> Uniquement si la fonction fait plus de dix lignes

]]> Erreur : une fonction courte peut cacher une erreur de
frontière.

]]> Spécification — Q29 : Ce que prouve un test réussi Les dix tests de la fonction tri passent tous. Que peut-on en
conclure ?

]]> Les tests augmentent la confiance ; seule une preuve, par invariant
par exemple, établit la correction.

]]> 1.0 0.0 0 true true abc Que la fonction est rapide sur ces dix listes

]]> Erreur : les tests vérifient le résultat, pas la vitesse.

]]> Qu'aucun de ces dix cas ne révèle d'erreur, rien de plus

]]> Bonne réponse : un test montre la présence d'une erreur quand il
échoue, pas son absence quand il réussit. D'autres cas peuvent
encore échouer.

]]> Que la spécification est bien écrite et complète

]]> Erreur : des tests peuvent réussir sur une fonction qui respecte
une spécification fausse.

]]> Que la fonction est correcte pour toutes les listes

]]> Erreur : dix cas ne couvrent pas l'infinité des listes
possibles.

]]> Spécification — Q30 : La valeur à tester en priorité La fonction est_majeur(age) doit renvoyer True à partir de
18 ans. Quelle valeur de age est la plus importante à tester ?

]]> Les cas limites, aux frontières de la spécification, sont ceux qui
révèlent le plus d'erreurs.

]]> 1.0 0.0 0 true true abc 5, un enfant, loin de toute frontière

]]> Erreur : même raison, 5 ne distingue pas > de >=.

]]> 40, un adulte typique, loin de toute frontière

]]> Erreur : une valeur loin de la frontière passe même avec une
comparaison mal écrite.

]]> 18, la frontière entre les deux réponses

]]> Bonne réponse : c'est là qu'une confusion entre > et >=
se révèle. Les valeurs 17 et 18 testent les deux côtés de
la frontière.

]]> 100, pour tester une grande valeur

]]> Erreur : rien de particulier ne se passe à 100 pour cette
fonction.

]]> Spécification — Q31 : Un jeu de tests pour une fonction sur les listes La fonction maximum(t) renvoie le plus grand élément d'une liste
non vide. Quel jeu de tests couvre le mieux les cas à risque ?

]]> Concevoir un jeu de tests, c'est imaginer comment la fonction
pourrait se tromper et écrire un cas pour chaque hypothèse.

]]> 1.0 0.0 0 true true abc Un élément seul, le maximum en dernière position, des doublons du maximum

]]> Bonne réponse : ces cas visent les erreurs classiques :
initialisation, parcours incomplet, comparaison stricte ou
large.

]]> Trois listes de cinq entiers tirés au hasard entre 0 et 100

]]> Erreur : des cas aléatoires passent à côté des situations
particulières où les bugs se cachent.

]]> Une seule liste longue, qui contient forcément tous les cas

]]> Erreur : une longue liste n'a qu'un seul maximum et qu'une seule
position pour lui.

]]> La liste vide, testée trois fois de suite

]]> Erreur : la liste vide viole la précondition ; la tester ne dit
rien de la fonction, et un seul cas ne vaut pas trois.

]]> Spécification — Q32 : Tester une fonction aléatoire La fonction de() renvoie un entier aléatoire entre 1 et 6.
Comment la tester, puisque son résultat change à chaque appel ?

]]> Quand la valeur exacte est imprévisible, on teste ce qui doit
toujours être vrai : bornes, type, répartition approximative.

]]> 1.0 0.0 0 true true abc En vérifiant que de() vaut 3, la valeur centrale

]]> Erreur : le résultat n'est pas fixé, ce test échouerait
souvent.

]]> En vérifiant sur mille appels que le résultat est entre 1 et 6

]]> Bonne réponse : faute de valeur attendue, on teste une
propriété que tout résultat doit respecter, sur un grand nombre
d'appels.

]]> En vérifiant qu'elle renvoie toujours la même valeur

]]> Erreur : ce serait précisément un signe de défaillance.

]]> En ne la testant pas, l'aléatoire étant intestable

]]> Erreur : les propriétés d'une fonction aléatoire se testent.

]]> Spécification — Q33 : Qui garantit la précondition La spécification de racine(x) indique la précondition « x est
positif ou nul ». À qui revient-il de la respecter ?

]]> Le contrat partage les responsabilités : l'appelant respecte la
précondition, la fonction assure la postcondition.

]]> 1.0 0.0 0 true true abc À celui qui appelle la fonction

]]> Bonne réponse : la précondition est une obligation de
l'appelant ; en échange, la fonction s'engage sur sa
postcondition.

]]> À personne, une précondition n'étant qu'une suggestion

]]> Erreur : hors de la précondition, le comportement n'est pas
garanti.

]]> À la fonction, qui doit corriger les arguments invalides

]]> Erreur : la fonction peut vérifier, mais pas inventer un
résultat pour un argument interdit.

]]> À Python, qui refuse les arguments invalides

]]> Erreur : Python ne connaît pas la spécification.

]]> Spécification — Q34 : La postcondition d'un maximum Quelle postcondition décrit complètement le résultat m de
maximum(t), pour une liste t non vide ?

]]> Une bonne postcondition est vérifiable et suffisante : elle
caractérise exactement le résultat attendu.

]]> 1.0 0.0 0 true true abc m est un entier positif, comme toutes les notes

]]> Erreur : le maximum d'une liste de négatifs est négatif, et
cette condition ne dit rien du lien avec t.

]]> m est dans t et aucun élément de t ne dépasse m

]]> Bonne réponse : les deux conditions sont nécessaires. Sans la
première, renvoyer un nombre énorme conviendrait ; sans la
seconde, n'importe quel élément conviendrait.

]]> m est le dernier élément de t, la liste étant triée

]]> Erreur : le maximum peut être n'importe où.

]]> m est plus grand que le premier élément de t

]]> Erreur : cette condition est insuffisante et même fausse quand
le premier élément est le maximum.

]]> Spécification — Q35 : Une précondition trop stricte Pour moyenne(notes), Sami écrit la précondition « notes
contient exactement cinq entiers entre 0 et 20 ». Quel est le
problème ?

]]> Une précondition minimale rend la fonction réutilisable ; une
précondition excessive la condamne à un seul usage.

]]> 1.0 0.0 0 true true abc Elle interdit des usages légitimes, comme une liste de trois notes

]]> Bonne réponse : une précondition doit être juste assez
restrictive pour que la fonction marche ; ici « liste non vide
de nombres » suffit.

]]> Les notes devraient être des flottants plutôt que des entiers

]]> Erreur : le type des notes n'est pas le problème.

]]> La fonction ne peut pas calculer une moyenne de cinq valeurs

]]> Erreur : elle le peut très bien, et bien d'autres tailles
aussi.

]]> Une précondition ne peut pas mentionner la longueur d'une liste

]]> Erreur : elle le peut ; la question est de savoir si c'est
nécessaire.

]]> Spécification — Q36 : Spécifier une fonction qui modifie son argument La fonction trier_sur_place(t) réordonne la liste t reçue et ne
renvoie rien. Que doit préciser sa spécification, en plus de la
précondition ?

]]> Un effet de bord fait partie du contrat : la docstring doit annoncer
ce que la fonction modifie en dehors d'elle.

]]> 1.0 0.0 0 true true abc Qu'elle modifie la liste passée en argument, son effet de bord

]]> Bonne réponse : l'appelant doit savoir que sa liste sera
changée et qu'aucune valeur ne sera renvoyée, sous peine
d'écrire t = trier_sur_place(t) et de perdre sa liste.

]]> Le nom de la variable à utiliser par l'appelant

]]> Erreur : l'appelant nomme ses variables comme il veut.

]]> Le nombre de comparaisons effectuées

]]> Erreur : le coût peut être documenté, mais ce n'est pas
l'information essentielle pour utiliser la fonction.

]]> Rien, une fonction sans return n'ayant pas besoin de spécification

]]> Erreur : c'est justement une fonction à effet de bord qui doit
le dire clairement.

]]> Spécification — Q37 : La postcondition complète d'un tri Pour une fonction trier(t) qui renvoie une nouvelle liste, la
postcondition « le résultat est trié par ordre croissant » est-elle
suffisante ?

]]> Une postcondition se vérifie en cherchant les résultats absurdes
qu'elle laisserait passer ; chaque faille appelle une condition
supplémentaire.

]]> 1.0 0.0 0 true true abc Oui, être trié suffit à définir le résultat d'un tri

]]> Erreur : une liste vide ou [1, 2, 3] sont triées sans avoir de
rapport avec t.

]]> Non, le résultat doit aussi contenir exactement les éléments de t

]]> Bonne réponse : sans cette condition, renvoyer la liste vide
respecterait la postcondition. Un tri conserve les éléments et
leurs répétitions.

]]> Non, il faut imposer que t soit modifiée sur place

]]> Erreur : la fonction renvoie une nouvelle liste ; t doit au
contraire rester intacte.

]]> Non, il faut préciser l'algorithme de tri utilisé

]]> Erreur : la spécification décrit le résultat, pas la méthode.

]]> Spécification — Q38 : La première ligne d'une docstring Que doit dire, en premier, la docstring d'une fonction ?

]]> Une docstring répond à la question « que fait cette fonction et
comment l'appeler ? », sans entrer dans le code.

]]> 1.0 0.0 0 true true abc Le nom de son auteur et son adresse

]]> Erreur : l'auteur peut figurer ailleurs, mais ce n'est pas ce
que cherche l'utilisateur de la fonction.

]]> La date d'écriture et de dernière modification

]]> Erreur : la date n'aide pas à utiliser la fonction.

]]> Le détail de chaque ligne de code

]]> Erreur : la docstring décrit l'usage, pas l'implémentation.

]]> Ce que fait la fonction, en une phrase

]]> Bonne réponse : la première ligne résume le rôle de la
fonction ; viennent ensuite les paramètres, la précondition et
le résultat.

]]> Spécification — Q39 : Que renvoyer quand il n'y a rien à renvoyer La fonction chercher(t, x) renvoie l'indice de x dans t.
Que doit préciser sa spécification pour le cas où x est absent ?

]]> Les cas particuliers font partie de la spécification : le résultat
doit être défini pour toute entrée respectant la précondition.

]]> 1.0 0.0 0 true true abc La valeur renvoyée en cas d'absence, par exemple -1 ou None

]]> Bonne réponse : sans cette précision, l'appelant ne sait pas
comment reconnaître l'absence, et des choix différents selon les
versions casseraient les programmes.

]]> Que la fonction affiche un message signalant l'absence

]]> Erreur : afficher n'aide pas le programme appelant, qui a besoin
d'une valeur exploitable.

]]> Que la fonction renvoie 0, premier indice valide

]]> Erreur : 0 est un indice possible pour x présent ; il ne
peut pas signaler l'absence.

]]> Rien, l'absence étant une erreur de l'appelant, hors contrat

]]> Erreur : chercher une valeur absente est un usage normal, pas
une violation de précondition.

]]>