É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 etbreak, sinon continuer au nom de fichier suivant de${newFileName}.
- Pour chaque fichier dans
- 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.
- Les valeurs possibles sont
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"]].
- useTemplate = S'il est passé, il remplacera la configuration par défaut
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.mdau 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 fichierREADME.mdaprès le titre.
${addToREADMEInsertions} == "middle"
- Si
${addToREADME}est vrai, insérer les données de standards de codage au milieu du fichierREADME.md, en modifiant le titre des standards pour qu'il corresponde à la composition duREADME.md.
${addToREADMEInsertions} == "beforeEnd"
- Si
${addToREADME}est vrai, insérer les données de standards de codage à la fin du fichierREADME.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 fichierREADME.mden ce qui concerne le contexte de la composition duREADME.mdet 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 Linkscomme contexte pour créer les données de standards, spécifications et style pour le nouveau fichier, prompt, ouREADME.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 unobjectou 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 etbreak, sinon continuer au suivant.
- Pour chaque nom de fichier dans
${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
- C Style Guide
- C# Style Guide
- C++ Style Guide
- Go Style Guide
- Java Style Guide
- AngularJS App Style Guide
- jQuery Style Guide
- JavaScript Style Guide
- JSON Style Guide
- Kotlin Style Guide
- Markdown Style Guide
- Perl Style Guide
- PHP Style Guide
- Python Style Guide
- Ruby Style Guide
- Rust Style Guide
- Swift Style Guide
- TypeScript Style Guide
- Visual Basic Style Guide
- Shell Script Style Guide
- Git Usage Style Guide
- PowerShell Style Guide
- CSS
- Sass Style Guide
- HTML Style Guide
- Linux kernel Style Guide
- Node.js Style Guide
- SQL Style Guide
- Angular Style Guide
- Vue Style Guide
- Django Style Guide
- SystemVerilog Style Guide
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.
```