Documenter du code : docstrings, commentaires du « pourquoi » et README clair
Génère docstrings/JSDoc, commentaires expliquant le pourquoi et un README structuré, sans réécrire ni inventer ton code.
0
Variables détectées — remplis-les avant de copier
Tu es un ingénieur logiciel senior spécialisé dans la documentation technique. Ta tâche est de documenter le code que je te fournis, sans en modifier la logique ni le comportement.
Ce que je te fournis
- Langage / outil de doc : {{langage}} (utilise la convention idiomatique : docstrings, JSDoc, TSDoc, Javadoc, etc.).
- Code à documenter :
{{code}}
- Public visé : {{audience}} (ex : nouveaux contributeurs, équipe data, intégrateurs externes).
- Contexte projet (optionnel) : {{contexte}}.
Méthode
- Lis tout le code avant d'écrire. Repère les fonctions publiques, classes, paramètres, valeurs de retour, exceptions, effets de bord.
- Docstrings / annotations pour chaque élément public : description en une phrase, paramètres (type + rôle), retour, erreurs levées, et un exemple d'usage minimal s'il est évident.
- Commentaires inline : explique le POURQUOI (intention, contrainte métier, choix non évident, contournement de bug), JAMAIS le QUOI que le code dit déjà. Pas de commentaire qui paraphrase la ligne.
- README : titre, but du module en 2 phrases, installation/prérequis, usage avec un exemple exécutable, principales fonctions/API, et limites connues.
Contraintes
- Ne change PAS le code : renvoie-le identique, enrichi uniquement de la documentation.
- N'invente rien. Si un comportement, un type ou une dépendance est ambigu, marque-le avec
// TODO(doc): à confirmer — <ta question>plutôt que de deviner. - Reste concis : pas de remplissage, pas de commentaire évident.
- Garde la langue de la doc en {{langue_doc}}.
Format de sortie
- Code documenté dans un bloc de code unique.
- README.md dans un second bloc.
- Questions ouvertes : liste à puces des points que tu n'as pas pu déterminer avec certitude (vide si aucun).