[ promptothèque ]

Rédiger une revue de code à partir d'un extrait

Commente un extrait de code selon les règles de l'équipe, en séparant ce qui bloque le merge de ce qui peut attendre.

DéveloppeursCodepremium

Mis à jour le 2 octobre 2026 · Fonctionne avec ChatGPT, Claude, Gemini, Le Chat (Mistral)

## Rôle
Tu relis du code pour des collègues. Tu commentes l'extrait fourni, tu cites la ligne ou l'expression en cause, et tu ne proposes pas de réécrire des fichiers qu'on ne t'a pas montrés.

## Tâche
Rédige la revue de cet extrait.

## Contexte
**Contexte :** {{contexte}}
**Extrait :**
{{extrait}}
**Règles attendues :** {{attendu}}

Chaque remarque s'appuie sur l'extrait ou sur une règle fournie. N'invente pas d'autre bug, d'autre fichier, ni de numéro de ticket. Si l'extrait ne permet pas de savoir si une règle est respectée, dis-le.

## Format de sortie
1. **Verdict** : merger, ou ne pas merger, en une phrase.
2. **Points qui bloquent**, chacun avec l'expression en cause et la règle que cela contredit.
3. **Points qui peuvent attendre.**
4. **Ce que l'extrait ne permet pas de vérifier.**

exemple

Ce que produit ce prompt

Résultat obtenu avec les valeurs d'exemple, avec Grok 4.7. Un autre modèle, ou le même à un autre moment, donnera un texte différent.

1. Verdict Ne pas merger : le chemin d'erreur renvoie un succès, et la condition compare deux identifiants qui ne sont pas du même objet.

2. Points qui bloquent

  • return { ok: true } dans le catch. Une erreur inattendue doit répondre 500. Ici, l'échec de paiement.capturer est présenté comme un succès.
  • rdv.userId == id. id est l'identifiant du rendez-vous passé à confirmer, userId est celui de l'utilisateur. La condition ne vérifie pas ce qu'elle semble vérifier. Les identifiants sont des chaînes : == ajoute une coercion inutile, il faut === une fois la comparaison corrigée.
  • rdv.userId est lu sans savoir si db.find a renvoyé un rendez-vous. Si rdv est vide, la lecture lève une erreur, que le catch ne voit pas puisqu'il est à l'intérieur du if. Cette erreur n'a donc aucun statut HTTP.
  • Si la condition est fausse, la fonction ne retourne rien. L'appelant n'a ni succès, ni 422, ni 500.

3. Points qui peuvent attendre Le nom confirmer et le retour { ok: true } du chemin heureux peuvent rester pour cette revue : aucune règle fournie ne les interdit. L'erreur métier en 422 ne peut pas être placée tant qu'on n'a pas dit quelle erreur métier paiement.capturer distingue d'une panne.

4. Ce que l'extrait ne permet pas de vérifier On ne voit pas le corps de db.find ni celui de paiement.capturer. On ne peut donc pas dire quelles erreurs sont métier et lesquelles sont inattendues.

Prompts liés