write-coding-standards-from-file

ファイルからコーディング標準を作成する

ファイルの既存の構文を使用して、プロジェクトの標準とスタイルガイドを確立します。複数のファイルまたはフォルダーが渡された場合は、各ファイルまたはフォルダー内のファイルをループ処理し、ファイルのデータを一時メモリまたはファイルに追加します。完了したら、一時データを単一のインスタンスとして使用します。つまり、それが標準とスタイルガイドの基盤となるファイル名であるかのように扱います。

ルールと構成

以下は、準構成の boolean および string[] 変数のセットです。各変数の true またはその他の値を処理する条件は、レベル 2 見出し ## Variable and Parameter Configuration Conditions の下にあります。

プロンプトのパラメーターにはテキスト定義があります。必須パラメーターが 1 つ ${fileName} あり、いくつかのオプションパラメーター ${folderName}、${instructions}、および任意の [configVariableAsParameter] があります。

構成変数

• addStandardsTest = false;
• addToREADME = false;
• addToREADMEInsertions = ["atBegin", "middle", "beforeEnd", "bestFitUsingContext"];
  • デフォルトは 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"];
  • ${newFileName} 内の各ファイルについて、ファイルが存在しない場合はそのファイル名を使用して break し、そうでない場合は ${newFileName} の次のファイル名に進みます。
• outputSpecToPrompt = false;
• useTemplate = "verbose"; // または "v"
  • 指定可能な値は [["v", "verbose"], ["m", "minimal"], ["b", "best fit"], ["custom"]] です。
  • プロンプトファイルの下部にあるレベル 2 見出し ## Coding Standards Templates の下の 2 つのサンプルテンプレートのいずれかを選択するか、より適合する別の構成を使用します。
  • custom の場合、リクエストごとに適用します。

プロンプトパラメーターとしての構成変数

いずれかの変数名がそのまま、または類似しているが明確に関連するテキスト値としてプロンプトに渡された場合、デフォルトの変数値をプロンプトに渡された値で上書きします。

プロンプトパラメーター

• fileName = 次の観点で分析されるファイルの名前: インデント、変数の命名、コメント、条件付き処理、関数的処理、およびファイルのコーディング言語に関連するその他の構文データ。
• folderName = 複数のファイルから 1 つの集約データセットにデータを抽出するために使用されるフォルダーの名前。これは次の観点で分析されます: インデント、変数の命名、コメント、条件付き処理、関数的処理、およびファイルのコーディング言語に関連するその他の構文データ。
• instructions = 固有のケースのために提供される追加の指示、ルール、および手順。
• [configVariableAsParameter] = 渡された場合、構成変数のデフォルト状態を上書きします。例:
  • useTemplate = 渡された場合、構成 ${useTemplate} のデフォルトを上書きします。値は [["v", "verbose"], ["m", "minimal"], ["b", "best fit"]] です。

必須およびオプションのパラメーター

• fileName - 必須
• folderName - オプション
• instructions - オプション
• [configVariableAsParameter] - オプション

変数とパラメーターの構成条件

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

• true の場合、${fixInconsistencies} を false に切り替えます。

${addToREADME} == true

• コーディング標準をプロンプトに出力したり新しいファイルを作成したりする代わりに、README.md に挿入します。
• true の場合、${createNewFile} と ${outputSpecToPrompt} の両方を false に切り替えます。

${addToREADMEInsertions} == "atBegin"

• ${addToREADME} が true の場合、コーディング標準データを README.md ファイルのタイトルの後の先頭に挿入します。

${addToREADMEInsertions} == "middle"

• ${addToREADME} が true の場合、コーディング標準データを README.md ファイルの中央に挿入し、標準のタイトル見出しを README.md の構成に合わせて変更します。

${addToREADMEInsertions} == "beforeEnd"

• ${addToREADME} が true の場合、コーディング標準データを README.md ファイルの末尾に挿入し、最後の文字の後に改行を挿入してから、新しい行にデータを挿入します。

${addToREADMEInsertions} == "bestFitUsingContext"

• ${addToREADME} が true の場合、README.md の構成とデータの流れのコンテキストを考慮して、コーディング標準データを README.md ファイルの最も適した行に挿入します。

${addStandardsTest} == true

• コーディング標準ファイルが完成したら、それに渡されたファイルまたは複数のファイルがコーディング標準に準拠していることを確認するためのテストファイルを書き込みます。

${createNewFile} == true

• ${newFileName} の値、または取り得る値のいずれかを使用して新しいファイルを作成します。
• true の場合、${outputSpecToPrompt} と ${addToREADME} の両方を false に切り替えます。

${fetchStyleURL} == true

• さらに、レベル3見出し ### Fetch Links の下にネストされたリンクから取得したデータを、新しいファイル、プロンプト、または README.md の標準、仕様、スタイリングデータを作成するためのコンテキストとして使用します。
• ### Fetch Links 内の関連する各項目について、#fetch ${item} を実行します。

${findInconsistencies} == true

• インデント、改行、コメント、条件分岐と関数のネスト、文字列の引用符のラッパー（' または "）などに関連する構文を評価し、カテゴリ分けします。
• 各カテゴリについてカウントを行い、1つの項目がカウントの過半数に一致しない場合は、一時メモリに記録します。
• ${fixInconsistencies} の状態に応じて、カウントの少ないカテゴリを過半数に一致するように編集および修正するか、一時メモリに保存された不整合をプロンプトに出力します。

${fixInconsistencies} == true

• 一時メモリに保存された不整合を使用して、構文データのカウントの少ないカテゴリを、対応する構文データの過半数に一致するように編集および修正します。

typeof ${newFileName} == "string"

• 明示的に string として定義されている場合、${newFileName} の値を使用して新しいファイルを作成します。

typeof ${newFileName} != "string"

• 明示的に string として定義されていない場合、代わりに object または配列である場合、次のルールを適用して ${newFileName} の値を使用して新しいファイルを作成します。
  • ${newFileName} 内の各ファイル名について、ファイルが存在しない場合はそのファイル名を使用して break し、そうでない場合は次に進みます。

${outputSpecToPrompt} == true

• ファイルを作成したり README に追加したりする代わりに、コーディング標準をプロンプトに出力します。
• true の場合、${createNewFile} と ${addToREADME} の両方を false に切り替えます。

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

• コーディング標準のデータを作成する際のガイドテンプレートとして、レベル3見出し ### "v", "verbose" の下のデータを使用します。

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

• コーディング標準のデータを作成する際のガイドテンプレートとして、レベル3見出し ### "m", "minimal" の下のデータを使用します。

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

• ${fileName} から抽出されたデータに応じて、レベル3見出し ### "v", "verbose" または ### "m", "minimal" の下のデータのいずれかを使用し、コーディング標準のデータを作成する際のガイドテンプレートとして最適な方を使用します。

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

• コーディング標準のデータを作成する際のガイドテンプレートとして、渡されたカスタムプロンプト、指示、テンプレート、またはその他のデータを使用します。

if ${fetchStyleURL} == true

プログラミング言語に応じて、以下のリストの各リンクについて #fetch (URL) を実行します（プログラミング言語が ${fileName} == [<Language> Style Guide] の場合）。

リンクを取得

• C スタイルガイド
• C# スタイルガイド
• C++ スタイルガイド
• Go スタイルガイド
• Java スタイルガイド
• AngularJS アプリスタイルガイド
• jQuery スタイルガイド
• JavaScript スタイルガイド
• JSON スタイルガイド
• Kotlin スタイルガイド
• Markdown スタイルガイド
• Perl スタイルガイド
• PHP スタイルガイド
• Python スタイルガイド
• Ruby スタイルガイド
• Rust スタイルガイド
• Swift スタイルガイド
• TypeScript スタイルガイド
• Visual Basic スタイルガイド
• Shell スクリプトスタイルガイド
• Git 使用スタイルガイド
• PowerShell スタイルガイド
• CSS
• Sass スタイルガイド
• HTML スタイルガイド
• Linux カーネルスタイルガイド
• Node.js スタイルガイド
• SQL スタイルガイド
• Angular スタイルガイド
• Vue スタイルガイド
• Django スタイルガイド
• SystemVerilog スタイルガイド

コーディング標準テンプレート

"m"、"minimal"

    ```markdown
    ## 1. Introduction
    *   **Purpose:** Briefly explain why the coding standards are being established (e.g., to improve code quality, maintainability, and team collaboration).
    *   **Scope:** Define which languages, projects, or modules this specification applies to.

    ## 2. Naming Conventions
    *   **Variables:** `camelCase`
    *   **Functions/Methods:** `PascalCase` or `camelCase`.
    *   **Classes/Structs:** `PascalCase`.
    *   **Constants:** `UPPER_SNAKE_CASE`.

    ## 3. Formatting and Style
    *   **Indentation:** Use 4 spaces per indent (or tabs).
    *   **Line Length:** Limit lines to a maximum of 80 or 120 characters.
    *   **Braces:** Use the "K&R" style (opening brace on the same line) or the "Allman" style (opening brace on a new line).
    *   **Blank Lines:** Specify how many blank lines to use for separating logical blocks of code.

    ## 4. Commenting
    *   **Docstrings/Function Comments:** Describe the function's purpose, parameters, and return values.
    *   **Inline Comments:** Explain complex or non-obvious logic.
    *   **File Headers:** Specify what information should be included in a file header, such as author, date, and file description.

    ## 5. Error Handling
    *   **General:** How to handle and log errors.
    *   **Specifics:** Which exception types to use, and what information to include in error messages.

    ## 6. Best Practices and Anti-Patterns
    *   **General:** List common anti-patterns to avoid (e.g., global variables, magic numbers).
    *   **Language-specific:** Specific recommendations based on the project's programming language.

    ## 7. Examples
    *   Provide a small code example demonstrating the correct application of the rules.
    *   Provide a small code example of an incorrect implementation and how to fix it.

    ## 8. Contribution and Enforcement
    *   Explain how the standards are to be enforced (e.g., via code reviews).
    *   Provide a guide for contributing to the standards document itself.
    ```

"v"、verbose"

    ```markdown

    # Style Guide

    This document defines the style and conventions used in this project.
    All contributions should follow these rules unless otherwise noted.

    ## 1. General Code Style

    - Favor clarity over brevity.
    - Keep functions and methods small and focused.
    - Avoid repeating logic; prefer shared helpers/utilities.
    - Remove unused variables, imports, code paths, and files.

    ## 2. Naming Conventions

    Use descriptive names. Avoid abbreviations unless well-known.

    | Item            | Convention           | Example            |
    |-----------------|----------------------|--------------------|
    | Variables       | `lower_snake_case`   | `buffer_size`      |
    | Functions       | `lower_snake_case()` | `read_file()`      |
    | Constants       | `UPPER_SNAKE_CASE`   | `MAX_RETRIES`      |
    | Types/Structs   | `PascalCase`         | `FileHeader`       |
    | File Names      | `lower_snake_case`   | `file_reader.c`    |

    ## 3. Formatting Rules

    - Indentation: **4 spaces**
    - Line length: **max 100 characters**
    - Encoding: **UTF-8**, no BOM
    - End files with a newline

    ### Braces (example in C, adjust for your language)

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

    ### Spacing

    - One space after keywords: `if (x)`, not `if(x)`
    - One blank line between top-level functions

    ## 4. Comments & Documentation

    - Explain *why*, not *what*, unless intent is unclear.
    - Keep comments up-to-date as code changes.
    - Public functions should include a short description of purpose and parameters.

    Recommended tags:

        ```text
        TODO: follow-up work
        FIXME: known incorrect behavior
        NOTE: non-obvious design decision
        ```

    ## 5. Error Handling

    - Handle error conditions explicitly.
    - Avoid silent failures; either return errors or log them appropriately.
    - Clean up resources (files, memory, handles) before returning on failure.

    ## 6. Commit & Review Practices

    ### Commits
    - One logical change per commit.
    - Write clear commit messages:

        ```text
        Short summary (max ~50 chars)
        Optional longer explanation of context and rationale.
        ```

    ### Reviews
    - Keep pull requests reasonably small.
    - Be respectful and constructive in review discussions.
    - Address requested changes or explain if you disagree.

    ## 7. Tests

    - Write tests for new functionality.
    - Tests should be deterministic (no randomness without seeding).
    - Prefer readable test cases over complex test abstraction.

    ## 8. Changes to This Guide

    Style evolves.
    Propose improvements by opening an issue or sending a patch updating this document.
    ```