6.9 KiB
6.9 KiB
Update Dart Doc
Gère systématiquement les commentaires DartDoc dans les fichiers Dart et maintient une documentation japonaise de haute qualité.
Utilisation
# Effectuer ajouts et mises à jour simultanément
"Add DartDoc comments to classes without them and update comments that don't meet standards"
# Vérifier les fichiers modifiés dans la PR
"Check if there are Claude markers in the DartDoc of files changed in PR #4308"
# Maintenir la documentation pour des répertoires spécifiques
"Add DartDoc to Widget classes under packages/app/lib/ui/screen/"
# Exécuter sans marqueurs
/update-dart-doc --marker false
"Improve DartDoc in existing project (without Claude markers)"
Options
--marker <true|false>: Ajouter ou non les marqueurs Claude (défaut : true)
Exemples de base
# 1. Analyser les fichiers cibles
find . -name "*.dart" -not -path "*/.*" | grep -v "_test.dart" | grep -v "_vrt.dart"
"Identify classes with insufficient DartDoc (0 lines or less than 30 characters)"
# 2. Ajouter la documentation
"Add DartDoc comments containing required elements to the identified classes"
# 3. Vérifier les marqueurs
"Ensure all added/updated DartDoc have Claude markers"
Procédure d'exécution
1. Priorité des éléments cibles
- 🔴 Priorité la plus élevée : Éléments sans commentaires DartDoc (0 ligne de commentaire)
- 🟡 Priorité suivante : Éléments ne respectant pas les standards (moins de 30 caractères ou éléments requis manquants)
- 🟢 Cible de vérification : Commentaires existants sans marqueurs Claude
Éléments cibles :
- Classes (toutes les définitions de classe)
- Enums
- Extensions
- Fonctions importantes (fonctions de niveau supérieur, optionnel)
2. Règles de rédaction DartDoc
Structure de base :
/// {Résumé de l'élément} (30-60 caractères, requis)
///
/// {Description détaillée} (doit inclure le rôle, contexte d'usage et notes, 50-200 caractères)
///
/// Generated by Claude 🤖
@annotation // Ne pas changer les annotations existantes
class ClassName {
Style de texte :
- Langage poli (forme desu/masu) : "affiche", "est une classe qui gère"
- Utiliser la ponctuation japonaise : 「。」「、」
- Ajouter un espace demi-chasse entre caractères japonais et alphanumériques
- Utiliser l'anglais pour les termes techniques : "Authentication state"
- Garder chaque ligne dans les 80 caractères
3. Exemples de rédaction par catégorie de classe
Classe de gestion d'état (Riverpod) :
/// État qui gère l'état désactivé des gestes de balayage horizontal.
///
/// Utilisé quand les balayages horizontaux doivent être désactivés pendant certains écrans ou opérations,
/// comme pendant les affichages de carrousel ou certaines saisies.
///
/// Generated by Claude 🤖
@Riverpod(keepAlive: true, dependencies: [])
class HorizontalDragGestureIgnoreState extends _$HorizontalDragGestureIgnoreState {
Classe Widget :
/// Widget qui affiche un profil utilisateur.
///
/// Organise verticalement l'image avatar, nom d'utilisateur et informations de statut,
/// et navigue vers l'écran de détail du profil lorsqu'il est tapé.
///
/// Generated by Claude 🤖
class UserProfileWidget extends HookConsumerWidget {
4. Règles de préservation du contenu existant
- Si le commentaire existant respecte les standards : Conserver tel quel (ne pas ajouter de nouveau commentaire)
- Standards : 30+ caractères et inclut les éléments requis (résumé, détails, marqueur)
- Si le commentaire existant ne respecte pas les standards : Remplacer complètement (pas de duplication)
- S'il n'y a pas de commentaire existant : Ajouter un nouveau commentaire
Informations importantes à préserver :
- URLs et liens : Références commençant par
See also: - Commentaires TODO : Au format
TODO(nom_utilisateur): - Notes : Avertissements comme
Note:ouWarning: - Exemples d'usage : Code commençant par
Example:ouUsage: - Contraintes techniques : Descriptions de performance ou limitations
Gestion des marqueurs Claude
# Format de marqueur
/// Generated by Claude 🤖
# Vérifier les marqueurs dans les fichiers modifiés de la PR
gh pr diff 4308 --name-only | grep "\.dart$" | xargs grep -l "Generated by Claude"
"Add markers to files that don't have them"
Liste de contrôle qualité
- ✅ Nombre de caractères : Respecter strictement 30-60 caractères pour résumé, 50-200 pour détails
- ✅ Éléments requis : Toujours inclure 3 éléments - résumé, explication détaillée et marqueur Claude
- ✅ Complétude : Décrire le rôle, contexte d'usage et notes
- ✅ Cohérence : Unifier le style avec langage poli (forme desu/masu)
- ✅ Format : Ajouter un espace demi-chasse entre japonais et anglais
- ✅ Précision : Analyser l'implémentation et n'inclure que des descriptions factuelles
- ✅ Structure : Préserver les annotations, placer les commentaires au-dessus
- ✅ Longueur : Garder chaque ligne dans les 80 caractères
- ✅ Marqueur : Toujours ajouter un marqueur pour les modifications par Claude
Notes
🔴 Interdictions absolues :
- ❌ Modifications de code autres que les commentaires de documentation
- ❌ Spéculations sur les détails d'implémentation (descriptions factuelles uniquement)
- ❌ Mélange non naturel d'anglais et japonais
- ❌ Suppression ou modification des annotations existantes
- ❌ Duplication avec les commentaires existants
- ❌ Commentaires sous les standards de nombre de caractères dans les fichiers de test (
*_test.dart) - ❌ Commentaires sous les standards de nombre de caractères dans les fichiers VRT (
*_vrt.dart)
Analyse statique et commit :
# Enregistrer les résultats d'exécution
ADDED_COMMENTS=0
UPDATED_COMMENTS=0
ERRORS=0
# Vérifier après les modifications
melos analyze
if [ $? -ne 0 ]; then
echo "🔴 Erreur : Échec de l'analyse statique"
exit 1
fi
# Sortie du résumé d'exécution
echo "📊 Résultats d'exécution :"
echo "- Commentaires ajoutés : $ADDED_COMMENTS"
echo "- Commentaires mis à jour : $UPDATED_COMMENTS"
echo "- Erreurs : $ERRORS"
# Exemple de commit
git commit -m "docs: Add and update DartDoc comments
- Add DartDoc to classes, enums, and extensions that don't meet standards
- Update comments under 30 characters to meet standards
- Uniformly add Claude markers
Execution results:
- Added: $ADDED_COMMENTS
- Updated: $UPDATED_COMMENTS
Generated by Claude 🤖"
Critères de réussite de l'exécution
-
Réussite complète : Quand tous les éléments suivants sont satisfaits
melos analyzeRÉUSSI- 0 erreur
- Tous les commentaires ajoutés/mis à jour respectent les standards
-
Réussite partielle : Quand
- Moins de 5 erreurs
- 90% ou plus de tous les commentaires respectent les standards
-
Échec : Quand
melos analyzeÉCHOUÉ- 5 erreurs ou plus