write-coding-standards-from-file

Par github · awesome-copilot

Rédige un document de normes de codage pour un projet, en te basant sur les styles de codage issus du ou des fichier(s) et/ou dossier(s) passés en arguments dans le prompt.

npx skills add https://github.com/github/awesome-copilot --skill write-coding-standards-from-file

Écrire les standards de codage à partir d'un fichier

Utiliser la syntaxe existante du ou des fichier(s) pour établir les standards et guides de style du projet. Si plus d'un fichier ou un dossier est fourni, parcourir chaque fichier ou fichiers du dossier, en ajoutant les données du fichier à la mémoire temporaire ou à un fichier, puis une fois terminé, utiliser les données temporaires comme une instance unique ; comme s'il s'agissait du nom du fichier sur lequel baser les standards et les lignes directrices de style.

Règles et configuration

Ci-dessous se trouve un ensemble de variables booléennes boolean et de tableaux string[] quasi-configuration. Les conditions de gestion de true, ou d'autres valeurs pour chaque variable, sont sous le titre de niveau deux ## Variable and Parameter Configuration Conditions.

Les paramètres du prompt ont une définition textuelle. Il y a un paramètre obligatoire ${fileName}, et plusieurs paramètres optionnels ${folderName}, ${instructions}, et tout [configVariableAsParameter].

Variables de configuration

  • addStandardsTest = false;
  • addToREADME = false;
  • addToREADMEInsertions = ["atBegin", "middle", "beforeEnd", "bestFitUsingContext"];
    • Défaut : beforeEnd.
  • createNewFile = true;
  • fetchStyleURL = true;
  • findInconsistencies = true;
  • fixInconsistencies = true;
  • newFileName = ["CONTRIBUTING.md", "STYLE.md", "CODE_OF_CONDUCT.md", "CODING_STANDARDS.md", "DEVELOPING.md", "CONTRIBUTION_GUIDE.md", "GUIDELINES.md", "PROJECT_STANDARDS.md", "BEST_PRACTICES.md", "HACKING.md"];
    • Pour chaque fichier dans ${newFileName}, si le fichier n'existe pas, utiliser ce nom de fichier et break, sinon continuer au nom de fichier suivant de ${newFileName}.
  • outputSpecToPrompt = false;
  • useTemplate = "verbose"; // ou "v"
    • Les valeurs possibles sont [["v", "verbose"], ["m", "minimal"], ["b", "best fit"], ["custom"]].
    • Sélectionne l'un des deux modèles d'exemple en bas du fichier prompt sous le titre de niveau deux ## Coding Standards Templates, ou utiliser une autre composition qui convient mieux.
    • Si custom, appliquer selon la demande.

Variables de configuration en tant que paramètres de prompt

Si l'un des noms de variables est passé au prompt tel quel, ou comme une valeur textuelle similaire mais clairement liée, remplacer la valeur par défaut de la variable par la valeur passée au prompt.

Paramètres du prompt

  • fileName = Le nom du fichier qui sera analysé en termes d'indentation, nommage des variables, commentaires, procédures conditionnelles, procédures fonctionnelles, et autres données syntaxiques relatives au langage de programmation du fichier.
  • folderName = Le nom du dossier qui sera utilisé pour extraire des données de plusieurs fichiers dans un ensemble de données agrégées qui sera analysé en termes d'indentation, nommage des variables, commentaires, procédures conditionnelles, procédures fonctionnelles, et autres données syntaxiques relatives au langage de programmation des fichiers.
  • instructions = Instructions additionnelles, règles et procédures qui seront fournies pour les cas particuliers.
  • [configVariableAsParameter] = S'il est passé, il remplacera l'état par défaut de la variable de configuration. Exemple :
    • useTemplate = S'il est passé, il remplacera la configuration par défaut ${useTemplate}. Les valeurs sont [["v", "verbose"], ["m", "minimal"], ["b", "best fit"]].

Paramètres obligatoires et optionnels

  • fileName - obligatoire
  • folderName - optionnel
  • instructions - optionnel
  • [configVariableAsParameter] - optionnel

Conditions de configuration des variables et paramètres

${fileName}.length > 1 || ${folderName} != undefined

  • Si vrai, basculer ${fixInconsistencies} à false.

${addToREADME} == true

  • Insérer les standards de codage dans le README.md au lieu de sortie au prompt ou de créer un nouveau fichier.
  • Si vrai, basculer à la fois ${createNewFile} et ${outputSpecToPrompt} à false.

${addToREADMEInsertions} == "atBegin"

  • Si ${addToREADME} est vrai, insérer les données de standards de codage au début du fichier README.md après le titre.

${addToREADMEInsertions} == "middle"

  • Si ${addToREADME} est vrai, insérer les données de standards de codage au milieu du fichier README.md, en modifiant le titre des standards pour qu'il corresponde à la composition du README.md.

${addToREADMEInsertions} == "beforeEnd"

  • Si ${addToREADME} est vrai, insérer les données de standards de codage à la fin du fichier README.md, en insérant une nouvelle ligne après le dernier caractère, puis en insérant les données sur une nouvelle ligne.

${addToREADMEInsertions} == "bestFitUsingContext"

  • Si ${addToREADME} est vrai, insérer les données de standards de codage à la ligne qui convient le mieux du fichier README.md en ce qui concerne le contexte de la composition du README.md et le flux de données.

${addStandardsTest} == true

  • Une fois le fichier de standards de codage terminé, écrire un fichier de test pour assurer que le ou les fichiers passés à celui-ci respectent les standards de codage.

${createNewFile} == true

  • Créer un nouveau fichier en utilisant la valeur, ou l'une des valeurs possibles, de ${newFileName}.
  • Si vrai, basculer à la fois ${outputSpecToPrompt} et ${addToREADME} à false.

${fetchStyleURL} == true

  • Utiliser en outre les données récupérées des liens imbriqués sous le titre de niveau trois ### Fetch Links comme contexte pour créer les données de standards, spécifications et style pour le nouveau fichier, prompt, ou README.md.
  • Pour chaque élément pertinent dans ### Fetch Links, exécuter #fetch ${item}.

${findInconsistencies} == true

  • Évaluer la syntaxe relative aux indentations, sauts de ligne, commentaires, imbrication conditionnelle et fonctionnelle, enveloppes de guillemets, c.-à-d. ' ou " pour les chaînes, etc., et catégoriser.
  • Pour chaque catégorie, faire un compte, et si un élément ne correspond pas à la majorité du compte, engager à la mémoire temporaire.
  • Selon l'état de ${fixInconsistencies}, soit modifier et corriger les catégories de faible compte pour correspondre à la majorité, soit sortir au prompt les incohérences stockées en mémoire temporaire.

${fixInconsistencies} == true

  • Modifier et corriger les catégories de syntaxe de faible compte pour correspondre à la majorité des données syntaxiques correspondantes en utilisant les incohérences stockées en mémoire temporaire.

typeof ${newFileName} == "string"

  • Si spécifiquement défini comme une string, créer un nouveau fichier en utilisant la valeur de ${newFileName}.

typeof ${newFileName} != "string"

  • Si NON spécifiquement défini comme une string, mais à la place un object ou un tableau, créer un nouveau fichier en utilisant une valeur de ${newFileName} en appliquant cette règle :
    • Pour chaque nom de fichier dans ${newFileName}, si le fichier n'existe pas, utiliser ce nom de fichier et break, sinon continuer au suivant.

${outputSpecToPrompt} == true

  • Sortir les standards de codage au prompt au lieu de créer un fichier ou d'ajouter à README.
  • Si vrai, basculer à la fois ${createNewFile} et ${addToREADME} à false.

${useTemplate} == "v" || ${useTemplate} == "verbose"

  • Utiliser les données sous le titre de niveau trois ### "v", "verbose" comme modèle directeur lors de la composition des données pour les standards de codage.

${useTemplate} == "m" || ${useTemplate} == "minimal"

  • Utiliser les données sous le titre de niveau trois ### "m", "minimal" comme modèle directeur lors de la composition des données pour les standards de codage.

${useTemplate} == "b" || ${useTemplate} == "best"

  • Utiliser soit les données sous le titre de niveau trois ### "v", "verbose" ou ### "m", "minimal", en dépendant des données extraites de ${fileName}, et utiliser le meilleur ajustement comme modèle directeur lors de la composition des données pour les standards de codage.

${useTemplate} == "custom" || ${useTemplate} == "<ANY_NAME>"

  • Utiliser le prompt personnalisé, les instructions, le modèle, ou d'autres données passées comme modèle directeur lors de la composition des données pour les standards de codage.

if ${fetchStyleURL} == true

Selon le langage de programmation, pour chaque lien dans la liste ci-dessous, exécuter #fetch (URL), si le langage de programmation est ${fileName} == [<Language> Style Guide].

Fetch Links

Modèles de standards de codage

"m", "minimal"

    ```markdown
    ## 1. Introduction
    *   **Purpose:** Expliquer brièvement pourquoi les standards de codage sont établis (par exemple, pour améliorer la qualité du code, la maintenabilité et la collaboration d'équipe).
    *   **Scope:** Définir quels langages, projets ou modules cette spécification s'applique.

    ## 2. Conventions de nommage
    *   **Variables:** `camelCase`
    *   **Fonctions/Méthodes:** `PascalCase` ou `camelCase`.
    *   **Classes/Structs:** `PascalCase`.
    *   **Constantes:** `UPPER_SNAKE_CASE`.

    ## 3. Formatage et style
    *   **Indentation:** Utiliser 4 espaces par indentation (ou tabulations).
    *   **Longueur de ligne:** Limiter les lignes à un maximum de 80 ou 120 caractères.
    *   **Accolades:** Utiliser le style « K&R » (accolade d'ouverture sur la même ligne) ou le style « Allman » (accolade d'ouverture sur une nouvelle ligne).
    *   **Lignes vierges:** Spécifier combien de lignes vierges utiliser pour séparer les blocs logiques de code.

    ## 4. Commentaires
    *   **Docstrings/Commentaires de fonction:** Décrire le but de la fonction, les paramètres et les valeurs de retour.
    *   **Commentaires inline:** Expliquer la logique complexe ou non évidente.
    *   **En-têtes de fichier:** Spécifier quelles informations doivent être incluses dans l'en-tête d'un fichier, comme l'auteur, la date et la description du fichier.

    ## 5. Gestion des erreurs
    *   **Général:** Comment gérer et enregistrer les erreurs.
    *   **Spécifiques:** Quels types d'exceptions utiliser et quelles informations inclure dans les messages d'erreur.

    ## 6. Meilleures pratiques et anti-modèles
    *   **Général:** Lister les anti-modèles courants à éviter (par exemple, les variables globales, les nombres magiques).
    *   **Spécifique au langage:** Recommandations spécifiques basées sur le langage de programmation du projet.

    ## 7. Exemples
    *   Fournir un petit exemple de code démontrant l'application correcte des règles.
    *   Fournir un petit exemple de code d'une implémentation incorrecte et comment la corriger.

    ## 8. Contribution et mise en application
    *   Expliquer comment les standards seront mis en application (par exemple, via des révisions de code).
    *   Fournir un guide pour contribuer au document de standards lui-même.

### `"v", verbose"`

```text
    ```markdown

    # Guide de style

    Ce document définit le style et les conventions utilisés dans ce projet.
    Toutes les contributions doivent suivre ces règles sauf indication contraire.

    ## 1. Style de code général

    - Favoriser la clarté plutôt que la brièveté.
    - Garder les fonctions et méthodes petites et ciblées.
    - Éviter de répéter la logique ; préférer les aides/utilitaires partagés.
    - Supprimer les variables inutilisées, les importations, les chemins de code et les fichiers.

    ## 2. Conventions de nommage

    Utiliser des noms descriptifs. Éviter les abréviations sauf si bien connues.

    | Élément         | Convention           | Exemple            |
    |-----------------|----------------------|--------------------|
    | Variables       | `lower_snake_case`   | `buffer_size`      |
    | Fonctions       | `lower_snake_case()` | `read_file()`      |
    | Constantes      | `UPPER_SNAKE_CASE`   | `MAX_RETRIES`      |
    | Types/Structs   | `PascalCase`         | `FileHeader`       |
    | Noms de fichier | `lower_snake_case`   | `file_reader.c`    |

    ## 3. Règles de formatage

    - Indentation : **4 espaces**
    - Longueur de ligne : **max 100 caractères**
    - Encodage : **UTF-8**, sans BOM
    - Terminer les fichiers par une nouvelle ligne

    ### Accolades (exemple en C, adapter pour votre langage)

        ```c
        if (condition) {
            do_something();
        } else {
            do_something_else();
        }
### Espacement

- Un espace après les mots clés : `if (x)`, pas `if(x)`
- Une ligne vierge entre les fonctions de haut niveau

## 4. Commentaires et documentation

- Expliquer *pourquoi*, pas *quoi*, sauf si l'intention n'est pas claire.
- Maintenir les commentaires à jour à mesure que le code change.
- Les fonctions publiques doivent inclure une brève description du but et des paramètres.

Balises recommandées :

    ```text
    TODO: travail de suivi
    FIXME: comportement incorrect connu
    NOTE: décision de conception non évidente
    ```

## 5. Gestion des erreurs

- Gérer explicitement les conditions d'erreur.
- Éviter les défaillances silencieuses ; soit retourner les erreurs, soit les enregistrer de manière appropriée.
- Nettoyer les ressources (fichiers, mémoire, handles) avant de retourner en cas d'échec.

## 6. Pratiques de commit et d'examen

### Commits
- Un changement logique par commit.
- Écrire des messages de commit clairs :

    ```text
    Résumé court (max ~50 caractères)
    Explication plus longue optionnelle du contexte et de la raison.
    ```

### Examens
- Garder les pull requests d'une taille raisonnable.
- Être respectueux et constructif dans les discussions d'examen.
- Adresser les changements demandés ou expliquer si vous n'êtes pas d'accord.

## 7. Tests

- Écrire des tests pour les nouvelles fonctionnalités.
- Les tests doivent être déterministes (pas d'aléatoire sans seed).
- Préférer les cas de test lisibles plutôt que l'abstraction de test complexe.

## 8. Modifications de ce guide

Le style évolue.
Proposer des améliorations en ouvrant un problème ou en envoyant un correctif mettant à jour ce document.
```

Skills similaires