$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 Son code source complet

]]> 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

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

]]> Sa vitesse d'exécution

]]> 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.

]]> La description précise de ce que la fonction doit faire (paramètres attendus, valeur renvoyée, conditions d'utilisation), indépendamment de l'implémentation

]]> 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 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.

]]> Son nom, ses paramètres (avec leurs types) 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:.

]]> Le numéro de ligne où la fonction est définie

]]> 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.

]]> 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.

]]> 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 d'arrêt de boucle

]]> 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.

]]> Une condition qui doit être vraie avant l'appel de la fonction (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 après l'appel

]]> Erreur : ce serait une postcondition.

]]> 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.

]]> 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 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.

]]> Le type de retour 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 »).

]]> Ce que la fonction garantit sur la valeur de retour (ou sur l'effet) après son exécution, si la précondition est respectée

]]> 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
conformément à la PEP 257 ?

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

]]> 1.0 0.0 0 true true abc Avec un commentaire placé en fin de fonction

]]> La convention est de
placer la docstring en
tout début de corps de
fonction, juste après
la signature.

]]> Avec une docstring (chaîne entre triples guillemets) en première instruction du corps

]]> Bonne réponse : def f(x): puis sur
la ligne suivante """description...""".
Accessible via help(f) ou f.__doc__.

]]> Avec un commentaire # au-dessus

]]> Lisible par l'humain mais inaccessible
dynamiquement.

]]> 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.

]]> 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
# x est un nombre
# renvoie sa valeur absolue
def valeur_absolue(x):
return abs(x)
`

]]> Acceptable mais moins idiomatique
(pas accessible via help).

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

]]> Code correct mais non documenté. La
spécification est implicite.

]]> ``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. Code self-documenting.

]]> `python
def valeur_absolue(x):
# implementation
pass
`

]]> Code non implémenté.

]]> 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 Parce que c'est obligatoire

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

]]> 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 clarifier le but de la fonction, faciliter la conception, permettre les tests, et servir de documentation

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

]]> 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.

]]> Spécification — Q08 : Annotations de type Que produisent les annotations de type en
Python (x: int) ?

]]> Annotations utiles pour : lisibilité, IDE
(auto-complétion, détection d'erreurs),
tests statiques. À combiner avec une
docstring claire.

]]> 1.0 0.0 0 true true abc Une erreur de syntaxe

]]> Erreur : syntaxe valide depuis Python 3.5.

]]> Une vérification automatique à l'exécution

]]> Erreur : Python n'applique pas les
annotations à l'exécution.

]]> Une transformation du type

]]> Erreur : pas de coercition.

]]> Une documentation du type attendu, vérifiable par des outils externes (mypy)

]]> Bonne réponse : annotations
informatives, sans effet à l'exécution
par défaut. Mais des outils statiques
peuvent les vérifier (mypy,
pyright).

]]> Spécification — Q09 : Doctest À quoi servent les exemples >>> ... dans une
docstring ?

]]> Format doctest :
`python
"""
>>> carre(3)
9
"""

Lancement : python -m doctest fichier.py`.

]]> 1.0 0.0 0 true true abc À déclarer des constantes du programme

]]> La déclaration de
constantes se fait par
affectation classique,
en dehors de toute
docstring.

]]> À fournir des exemples d'utilisation qui peuvent être exécutés automatiquement comme tests par le module doctest

]]> Bonne réponse : double avantage,
documentation et tests vérifiés. Le
module doctest extrait ces exemples
et vérifie qu'ils fonctionnent.

]]> À rendre la documentation plus jolie visuellement

]]> Cette interprétation est
trop superficielle. Ces
exemples ont un rôle
fonctionnel précis,
comme expliqué dans la
bonne réponse.

]]> À signaler une erreur dans le code

]]> Aucun rapport. Les
exemples >>> sont des
extraits exécutables,
conçus pour illustrer
le comportement attendu
de la fonction.

]]> 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 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, liste à un élément, liste très longue

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

]]> 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.

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

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

]]> Spécification — Q11 : Programmation par contrat Que signifie « programmation par contrat » ?

]]> Bénéfices : robustesse, débogage facile
(violation de contrat = origine du bug).
Outils : assert en Python pour vérifier
pré/post à l'exécution.

]]> 1.0 0.0 0 true true abc Rédiger un contrat juridique pour chaque programme

]]> Le mot « contrat » est
ici employé au sens
informatique, sans
rapport avec le droit.

]]> Programmer à plusieurs au sein d'une même équipe

]]> Cette interprétation
littérale est sans
rapport avec le sens
technique de
l'expression
« programmation par
contrat ».

]]> Concevoir chaque fonction avec un contrat explicite (préconditions, postconditions, invariants), respecté par l'appelant et par la fonction

]]> Bonne réponse : approche introduite par
Bertrand Meyer (langage Eiffel).
Chacune des deux parties (appelant,
fonction) a des obligations.

]]> Programmer en échange d'une rémunération financière

]]> Cette interprétation
littérale n'a aucun
rapport avec le sens
technique du terme.

]]> 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 Aucune précondition n'est nécessaire

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

]]> 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.

]]> 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.

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

]]> Docstring minimale = description courte +
paramètres + retour. Docstring complète =
ajouter exemples, exceptions levées,
remarques.

]]> 1.0 0.0 0 true true abc Une description du but, des paramètres (avec types), de la valeur renvoyée, des conditions d'utilisation et idéalement des exemples

]]> Bonne réponse : informations utiles à
l'utilisateur sans qu'il ait besoin de
lire le code. Plusieurs styles de
docstring : Google, NumPy, Sphinx.

]]> Uniquement le nom de l'auteur de la fonction

]]> 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.

]]> Un poème ou un texte décoratif

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

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

]]> help() est un raccourci interactif. Sur
les IDE modernes, on a la même chose au
survol. Toujours documenter pour aider
les futurs lecteurs (y compris soi-même).

]]> 1.0 0.0 0 true true abc Elle lance la documentation en ligne sur Internet

]]> Cette description est
imprécise. La fonction
help consulte la
documentation locale,
fournie par les
docstrings du programme,
et non une ressource en
ligne.

]]> 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.

]]> Affiche la signature de la fonction et sa docstring (si elle en a une)

]]> Bonne réponse : c'est pourquoi
documenter via docstring est utile.
Visible directement dans
l'interpréteur ou les IDE.

]]> Renvoie le code source

]]> Erreur : help montre la docstring,
inspect.getsource donne le code.

]]> Spécification — Q15 : Programmation défensive Que signifie « programmation défensive » ?

]]> `python
def racine(x):
if x < 0:
raise ValueError("x doit être ≥ 0")
return x ** 0.5
`
Plus robuste, mais plus verbeux. À doser
selon le contexte.

]]> 1.0 0.0 0 true true abc Programmer un système de sécurité physique

]]> Cette interprétation
littérale ne correspond
pas au sens technique du
terme en programmation.

]]> S'abstenir d'écrire du code

]]> La programmation
défensive consiste au
contraire à ajouter des
vérifications dans le
code, et non à se
dispenser d'en écrire.

]]> Vérifier explicitement dans la fonction que les préconditions sont respectées (lever une exception si ce n'est pas le cas), au lieu de faire confiance à l'appelant

]]> Bonne réponse : compromis entre
robustesse et performance. Souvent
recommandé pour les fonctions exposées à
un usage extérieur.

]]> Ajouter des virus de défense au programme

]]> Cette description
fantaisiste n'a aucun
rapport avec le sens
technique du terme.

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

]]> Annotations de type : int, float,
str, bool, list[int], dict[str,
int], Optional[int] (= int | None).
Très utiles dans les gros projets.

]]> 1.0 0.0 0 true true abc Pour clarifier ce que reçoit l'appelant et permettre les vérifications statiques (mypy)

]]> Bonne réponse : par exemple,
def chercher(...) -> int | None
indique qu'on peut recevoir None,
ce qui doit être traité par
l'appelant.

]]> 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.

]]> Cela rend la fonction 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.

]]> C'est obligatoire en Python

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

]]> 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 m(l):

]]> Noms peu informatifs. Pas idéal.

]]> def moyenne(x):

]]> Acceptable mais sans typage. On peut
mieux faire.

]]> 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 calc(*args, kwargs):

]]> Trop générique : on ne sait pas ce que
la fonction fait.

]]> 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 liste de cent notes

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

]]> La liste vide, qui provoque une division 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 décimale, par exemple 12{,}5

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

]]> 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.

]]> 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 forçant à réfléchir aux entrées valides, aux cas limites et aux comportements attendus, ce qui réduit les bugs et facilite les tests

]]> 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 des types forts

]]> Pas spécifiquement.

]]> Spécification — Q20 : Outils Python Quels outils Python aident à respecter une
spécification ?

]]> assert preconditon, "message" est très
utilisé pour documenter et vérifier les
contrats. À utiliser en développement,
éventuellement désactivable en production
avec python -O.

]]> 1.0 0.0 0 true true abc Annotations de type + mypy (vérification statique), assert (vérification à l'exécution), doctest (tests d'exemples), unittest/pytest (tests unitaires)

]]> Bonne réponse : écosystème riche.
Combinés, ils permettent de garantir
la conformité aux spécifications avec
un fort niveau de confiance.

]]> Aucun

]]> Erreur : il existe plusieurs outils.

]]> Un compilateur

]]> Python n'est pas compilé en standard.

]]> Seulement print

]]> print aide à déboguer, pas à
spécifier.

]]> 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

]]> Erreur : trop ambiguë.

]]> Plusieurs zones d'ombre : que renvoyer si trouvée (indice, booléen) ? Si plusieurs occurrences (la première, toutes) ? Si absente (None, -1, exception) ?

]]> 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 (raise ValueError(...)) ;
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 Faire planter le programme

]]> 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 de retour spéciale (None, -1), exception levée, ou contrat (précondition que l'utilisateur doit garantir)

]]> 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'on peut réécrire l'implémentation sans changer le contrat, donc sans casser le code qui l'utilise

]]> Bonne réponse : c'est l'abstraction.
Tant que la spec est respectée, l'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.

]]> 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.

]]> Parce qu'elle élimine totalement 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.

]]> Spécification — Q24 : Développement piloté par les tests En quoi consiste l'approche dite de
développement piloté par les tests ?

]]> Les bénéfices de cette démarche sont un
code minimal et bien testé, ainsi qu'une
conception guidée par le besoin réel.
Elle requiert toutefois un apprentissage et
une discipline soutenue. Largement
reconnue dans l'industrie, elle n'est pas
pour autant universelle.

]]> 1.0 0.0 0 true true abc Tester manuellement le programme une fois qu'il est entièrement écrit

]]> Cette description correspond à un test
manuel classique, et non à l'approche
pilotée par les tests, qui inverse
précisément la chronologie habituelle.

]]> Faire générer automatiquement les tests par un programme d'intelligence artificielle

]]> Cette approche est conduite par un
humain, et non par un système
automatique. Le programmeur écrit
lui-même les tests à partir de la
spécification.

]]> Écrire d'abord les tests à partir de la spécification, puis le code juste suffisant pour les faire passer, et enfin retravailler la structure du code à tests inchangés

]]> Cette démarche en trois étapes (test,
code, refactorisation) oblige à bien
spécifier le comportement attendu avant
de coder. Elle s'oppose à l'approche
intuitive, qui consiste à coder
d'abord et tester ensuite.

]]> Exécuter les tests sur un seul ordinateur, plutôt que sur plusieurs

]]> Le matériel utilisé pour exécuter les
tests n'a aucun rapport avec cette
démarche.

]]> 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 une condition que la fonction doit garantir au moment de 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 docstring permet d'accéder à la documentation via help()

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

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

]]> Vrai : définition standard.

]]> 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 adjectivé comme sorted ou
participe reversed 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 indique clairement si la
fonction modifie la liste reçue (effet
de bord, exemple : liste.sort() qui
renvoie None), ou si elle construit
une nouvelle liste triée sans toucher à
la liste d'entrée (exemple : sorted(liste))

]]> 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 se fait au moment de l'exécution, en fonction de la mémoire disponible

]]> 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 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 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 la précondition et la postcondition

]]> 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 porte sur les paramètres
au moment de l'appel ; la postcondition
porte sur la valeur renvoyée ou l'état
final ; l'invariant de boucle porte sur
une propriété conservée à chaque
itération de la boucle interne

]]> 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.

]]> 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.

]]>