Programmation pour l'examen : des réponses en Python qui marquent des points

Les correcteurs d'examen n'exécutent pas votre code dans un débogueur pendant vingt minutes. Ils le lisent une fois, peut-être deux, et le vérifient par rapport à une grille de notation. Une solution qui fonctionne mais ignore la grille peut quand même perdre des points, tandis qu'une solution légèrement moins soignée qui cocher tous les points de contrôle peut scorer plus haut. Écrire du Python pour un examen est une compétence différente d'écrire du Python pour un vrai projet, et c'est worth d'entraîner séparément.

Lisez la grille avant de relire le problème deux fois

La plupart des examens de programmation — questions en réponse libre style AP CS A, examens de mi-semestre universitaire, évaluations de bootcamp de codage — publient des règles de crédit partiel. Une ligne de grille typique ressemble à : « 1 point pour une structure de boucle correcte, 1 point pour une valeur de retour correcte, 1 point pour gérer le cas de liste vide. » Si vous écrivez une one-liner dense qui donne la bonne réponse mais saute une boucle explicite, certains correcteurs vous ôteront des points même si le résultat est correct.

Avant de taper quoi que ce soit, identifiez les éléments qu'un correcteur est susceptible de vérifier séparément :

• La signature de fonction correspond exactement à ce qui a été demandé (nom, ordre des paramètres, type de retour)
• Cas de base et cas récursif, si la récursion est attendue
• Limites de boucle (les erreurs off-by-one sont la perte de points la plus courante)
• Cas limites : entrée vide, entrée à un seul élément, nombres négatifs, doublons

Écrivez d'abord ces éléments en tant que commentaires. # handle empty list, # base case: n == 0. Cela prend dix secondes et garantit que vous n'oubliez pas le cas qu'un correcteur cherche spécifiquement.

Structurez le code pour que le crédit partiel soit visible

Comparez deux réponses à « écrivez une fonction qui retourne le deuxième plus grand nombre dans une liste » :

def second_largest(nums):
    return sorted(nums)[-2]

def second_largest(nums):
    if len(nums) < 2:
        return None
    largest = second = float('-inf')
    for n in nums:
        if n > largest:
            second = largest
            largest = n
        elif n > second and n != largest:
            second = n
    return second

La première est correcte pour une entrée bien formée mais plante sur une liste avec moins de deux éléments et donne une mauvaise réponse sur les doublons comme [5, 5, 3] (retourne 5, potentiellement faux selon la spécification). La deuxième est plus longue mais chaque ligne de grille — cas limite, logique correcte, retour correct — est explicite et obtient sa propre ligne qu'un correcteur peut cocher. À un examen chronométré, la deuxième version score plus haut presque à chaque fois, même si elle prend plus longtemps à taper.

N'optimisez pas prématurément, ne laissez pas non plus de bugs évidents

Les questions d'examen testent rarement la connaissance de Big-O à moins qu'elles ne le disent directement. Si l'énoncé dit « écrivez une fonction qui trouve les doublons », une boucle imbriquée en O(n²) est acceptable sauf si l'énoncé spécifie une entrée large ou demande une solution efficace. Dépenser du temps à l'examen pour convertir en une approche basée sur set en O(n) quand ce n'était pas demandé est du temps que vous ne récupérerez pas.

Cela dit, certaines erreurs vous coûteront toujours des points indépendamment de la grille :

• Utiliser == au lieu de is de manière incohérente causant des bugs logiques (rare dans les examens Python mais apparaît dans les questions lourdes en comparaisons)
• Muter une liste tout en itérant dessus — for x in lst: lst.remove(x) est un classique piège d'examen qui produit une sortie silencieusement fausse
• Oublier return et imprimer à la place — de nombreux autograders vérifient les valeurs de retour, pas stdout
• Off-by-one dans range() — range(len(nums)) vs range(len(nums) - 1) est worth de vérifier à chaque fois que vous l'écrivez

Tracez votre code à la main avant de soumettre

Aux examens sur papier et à la plupart des examens de codage en ligne, vous n'avez pas la possibilité d'exécuter le code. Choisissez un petit exemple et tracez-le ligne par ligne, en notant les valeurs des variables au fur et à mesure. Cela capture environ 80% des erreurs de logique en moins de deux minutes, et c'est la chose à plus forte valeur que vous pouvez faire avec le temps restant.

Pour les fonctions récursives spécifiquement, tracez au moins deux niveaux de profondeur et écrivez explicitement le cas de base atteint. Les correcteurs accordent souvent un point juste pour démontrer que le cas de base se termine correctement, séparé du point pour que le cas récursif soit correct.

Gérez l'horloge comme une ressource, pas une après-réflexion

Si une section de réponse libre vaut 9 points répartis sur trois sous-questions, budgétisez grosso modo un temps égal et avancez si vous êtes bloqué au-delà de ce budget — une partie (b) à moitié écrite mais presque correcte vaut plus de points bruts qu'une partie (a) parfaite et une partie (c) vierge. Écrivez une fonction stub avec la bonne signature et un pass ou une devinez même si vous ne pouvez pas finir la logique ; une signature correcte seule vaut parfois un point de grille en soi.

Pour plus d'informations sur l'écriture de Python propre et testable en dehors de la salle d'examen, et sur les structures de données qui apparaissent constamment dans ces questions, consultez les segments Python et Computer Science connexes sur Korra Studio.