Contenus | Capacités attendues | Commentaires |
---|---|---|
Mise au point des programmes. Gestion des bugs. | Dans la pratique de la programmation, savoir répondre aux causes typiques de bugs : problèmes liés au typage, effets de bord non désirés, débordements dans les tableaux, instruction conditionnelle non exhaustive, choix des inégalités, comparaisons et calculs entre flottants, mauvais nommage des variables, etc. | On prolonge le travail entrepris en classe de première sur l’utilisation de la spécification, des assertions, de la documentation des programmes et de la construction de jeux de tests. Les élèves apprennent progressivement à anticiper leurs erreurs. |
La mise au point du programme doit permettre au programme de répondre à une spécification, durant cette phase, le programmeur se doit de savoir répondre aux causes typiques de bugs.
Durant la phase de conception d'un programme, on commence par écrire la spécification du programme, et écrire des jeux de tests pour valider le fonctionnement du programme.
La spécification décrit les entrées et sorties du programme, ainsi que leurs types, ce que l'on appelle en anglais l'API(Application Programming Interface) ou interface de programmation applicative en francais(peu courant).
Les tests vérifient que les sorties du programme sont conformes à ce que l'on attend.
Voici une fonction avec sa spécification.
def est_pair(n):
"""Indique si un nombre est pair ou non
Paramètres
----------
n: int
Returns
-------
bool
True si n est pair, False sinon
"""
if n % 2 == 0:
return True
else:
return False
Maintenant un ensemble de tests:
assert est_pair(2) == True
assert est_pair(5) == False
assert est_pair(1381635162) == True
assert est_pair(-3565454165461) == False
# le == True est redondant
assert est_pair(4)
# le == False peut être écrit
assert not(est_pair(5))
Il est important de bien distinguer commenter et documenter.
Dans un tri, on pourrait trouver le code suivant.
# on part du deuxième élément car il est déjà trié
for i in range(1, len(tab)):
...
Le commentaire explique ce que l'on a fait, et évite de revenir en arrière si quelqu'un ne comprend pas pourquoi on est parti de l'indice 1.
En Python, la documentation se fait par l'écriture de Docstrings.
Une docstring est une chaîne de caractère écrite en tant que première instruction dans une
définition de module, fonction, classe ou méthode. Une telle docstring devient l'attribut spécial
__doc__
de cet objet, et pourra être affichée grâce à la fonction help()
.
On peut accéder à la Docstring de la fonction est_pair
écrite précédemment comme ceci.
help(est_pair)
Affiche :
Help on function est_pair in module __main__:
est_pair(n)
Indique si un nombre est pair ou non
Paramètres
----------
n: int
Returns
-------
bool
True si n est pair, False sinon
Lors de l'écriture de code Python, vous ferez fréquemment des erreurs, qui vous serons "gentiment" rappelées par l'interpréteur Python à l'exécution du code.
Voici les erreurs les plus courantes :
SyntaxError
erreur de parenthèse, :
manquant avant un bloc
d'instruction.... ex: len([1,2,3))
IndexError
accés à un index non présent dans une liste. ex:
[12,15,14][14],;
NameError
nom de fonction ou de variable mal orthographié. ex:
helpe(est_pair)
IndentationError
indentation oubliée, ou trop grande.TypeError
Opération impossible entre deux types. ex: "3" * "5"