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

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

ルールと設定

以下は、準設定用の boolean と string[] 変数のセットです。各変数の true または他の値に対する条件は、レベル2の見出し ## 変数とパラメータ設定の条件 の下にあります。

プロンプトのパラメータにはテキスト定義があります。${fileName} という1つの必須パラメータと、${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の見出し ## コーディング標準テンプレート の下にある2つのサンプルテンプレートの1つを選択するか、より適合する別の構成を使用します。
  • 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} の値または可能な値の1つを使用して新しいファイルを作成します。
• 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] である場合。

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

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

"m", "minimal"

    ```markdown
    ## 1. 導入
    *   **目的:** コーディング標準が確立される理由を簡潔に説明します（例：コード品質、保守性、チーム協業の改善）。
    *   **スコープ:** この仕様が適用される言語、プロジェクト、またはモジュールを定義します。

    ## 2. 命名規則
    *   **変数:** `camelCase`
    *   **関数/メソッド:** `PascalCase` または `camelCase`。
    *   **クラス/構造体:** `PascalCase`。
    *   **定数:** `UPPER_SNAKE_CASE`。

    ## 3. フォーマットとスタイル
    *   **インデント:** インデント1つあたり4スペース（またはタブ）を使用します。
    *   **行の長さ:** 行を最大80文字または120文字に制限します。
    *   **括弧:** "K&R" スタイル（開き括弧を同じ行に）または "Allman" スタイル（開き括弧を新しい行に）を使用します。
    *   **空行:** コードの論理的なブロックを分離するための空行の数を指定します。

    ## 4. コメント
    *   **ドキュメント文字列/関数コメント:** 関数の目的、パラメータ、および戻り値について説明します。
    *   **インラインコメント:** 複雑または非明白なロジックを説明します。
    *   **ファイルヘッダー:** ファイルヘッダーに含めるべき情報を指定します（例：作成者、日付、ファイルの説明）。

    ## 5. エラーハンドリング
    *   **一般:** エラーのハンドリングとログの方法。
    *   **具体的:** 使用する例外タイプと、エラーメッセージに含める情報。

    ## 6. ベストプラクティスとアンチパターン
    *   **一般:** 回避すべき一般的なアンチパターンをリストアップします（例：グローバル変数、マジックナンバー）。
    *   **言語固有:** プロジェクトのプログラミング言語に基づく具体的な推奨事項。

    ## 7. 例
    *   ルールを正しく適用することを示す小さなコード例を提供します。
    *   間違った実装の小さなコード例と修正方法を提供します。

    ## 8. 貢献と執行
    *   標準がどのように執行されるか説明します（例：コードレビュー経由）。
    *   標準ドキュメント自体への貢献ガイドを提供します。
    ```

"v", "verbose"

    ```markdown

    # スタイルガイド

    このドキュメントは、このプロジェクトで使用されるスタイルと規則を定義します。
    特に記載がない限り、すべての貢献はこれらのルールに従う必要があります。

    ## 1. 一般的なコードスタイル

    - 簡潔さより明確さを優先します。
    - 関数とメソッドは小さく、焦点を絞った状態に保ちます。
    - ロジックの繰り返しを避けます。共有ヘルパー/ユーティリティを優先します。
    - 未使用の変数、インポート、コードパス、ファイルを削除します。

    ## 2. 命名規則

    説明的な名前を使用します。よく知られていない限り、略語は避けます。

    | アイテム            | 規則           | 例            |
    |-----------------|----------------------|--------------------|
    | 変数       | `lower_snake_case`   | `buffer_size`      |
    | 関数       | `lower_snake_case()` | `read_file()`      |
    | 定数       | `UPPER_SNAKE_CASE`   | `MAX_RETRIES`      |
    | 型/構造体   | `PascalCase`         | `FileHeader`       |
    | ファイル名      | `lower_snake_case`   | `file_reader.c`    |

    ## 3. フォーマットルール

    - インデント: **4スペース**
    - 行の長さ: **最大100文字**
    - エンコーディング: **UTF-8**、BOM なし
    - ファイルを改行で終了します

    ### 括弧（C言語の例、言語に応じて調整）

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

    ### 間隔

    - キーワードの後に1つのスペース: `if (x)`, not `if(x)`
    - トップレベル関数間に1つの空行

    ## 4. コメントとドキュメント

    - *何* ではなく *なぜ* を説明します。意図が不明な場合を除きます。
    - コメントをコードの変更に伴って最新の状態に保ちます。
    - パブリック関数には目的とパラメータの短い説明を含める必要があります。

    推奨タグ:

        ```text
        TODO: フォローアップ作業
        FIXME: 既知の誤ったビヘイビア
        NOTE: 非自明な設計上の決定
        ```

    ## 5. エラーハンドリング

    - エラー条件を明示的にハンドルします。
    - サイレント失敗を避けます。エラーを返すか、適切にログを記録するかのいずれかです。
    - 失敗時に戻る前に、リソース（ファイル、メモリ、ハンドル）をクリーンアップします。

    ## 6. コミットとレビュープラクティス

    ### コミット
    - 1つのコミット1つの論理的な変更。
    - 明確なコミットメッセージを書きます：

        ```text
        簡潔な概要（最大約50文字）
        コンテキストと論理の選択的なより長い説明。
        ```

    ### レビュー
    - プルリクエストは適切なサイズに保ちます。
    - レビューの議論では敬意を払い、建設的です。
    - 要求された変更に対応するか、異なる場合はその理由を説明します。

    ## 7. テスト

    - 新しい機能用のテストを作成します。
    - テストは確定的です（シード処理なしでランダム性がない）。
    - 複雑なテスト抽象化より読みやすいテストケースを優先します。

    ## 8. このガイドへの変更

    スタイルは進化します。
    このドキュメントを更新するイシューをオープンするか、パッチを送信して改善を提案します。
    ```