write-coding-standards-from-file

從檔案撰寫編碼標準

利用現有檔案的語法來建立專案的編碼標準與風格指南。如果傳入多個檔案或一個資料夾，則逐一處理每個檔案或資料夾中的檔案，將檔案資料附加到暫存記憶體或檔案中，完成後將暫存資料視為單一實例，作為制定標準與風格指南的依據。

規則與設定

以下是一組準設定用的 boolean 與 string[] 變數。各變數在 true 或其他值時的處理條件，請參見二級標題 ## Variable and Parameter Configuration Conditions。

提示詞的參數有文字定義。有一個必要參數 ${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，否則繼續到下一個檔名。
outputSpecToPrompt = false;
useTemplate = "verbose"; // 或 "v"
- 可能的值為 [["v", "verbose"], ["m", "minimal"], ["b", "best fit"], ["custom"]]。
- 選取提示詞檔案底部二級標題 ## Coding Standards Templates 下的兩個範本之一，或使用更合適的其他組合。
- 若為 custom，則依請求自訂。

作為提示詞參數的設定變數

如果任何變數名稱以原樣或相似但明確相關的文字值傳入提示詞，則以傳入的值覆蓋預設變數值。

提示詞參數

fileName = 要分析的檔案名稱，分析項目包括：縮排、變數命名、註解、條件式、函式以及其他與檔案程式語言相關的語法資料。
folderName = 要從中提取多個檔案資料並彙總成單一資料集的資料夾名稱，分析項目包括：縮排、變數命名、註解、條件式、函式以及其他與檔案程式語言相關的語法資料。
instructions = 針對特殊情況提供的額外指示、規則與程序。
[configVariableAsParameter] = 若傳入，則覆蓋設定變數的預設狀態。例如：
- useTemplate = 若傳入，則覆蓋設定 ${useTemplate} 的預設值。值為 [["v", "verbose"], ["m", "minimal"], ["b", "best fit"]]。

必要與選用參數

fileName - 必要
folderName - 選用
instructions - 選用
[configVariableAsParameter] - 選用

Variable and Parameter Configuration Conditions

`${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`

另外使用三級標題 ### Fetch Links 下連結中取得的資料，作為建立新檔案、提示詞或 README.md 的標準、規格與樣式資料的參考。
對於 ### Fetch Links 中的每個相關項目，執行 #fetch ${item}。

`${findInconsistencies} == true`

評估與縮排、換行、註解、條件式與函式巢狀結構、字串引號（例如 ' 或 "）等相關的語法，並進行分類。
對每個分類進行計數，若某項目與多數不符，則將其存入暫存記憶體。
根據 ${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"`

使用三級標題 ### "v", "verbose" 下的資料作為撰寫編碼標準時的引導範本。

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

使用三級標題 ### "m", "minimal" 下的資料作為撰寫編碼標準時的引導範本。

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

根據從 ${fileName} 提取的資料，選用三級標題 ### "v", "verbose" 或 ### "m", "minimal" 下的資料，並使用最合適的作為撰寫編碼標準時的引導範本。

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

使用自訂的提示詞、指示、範本或其他傳入的資料作為撰寫編碼標準時的引導範本。

if `${fetchStyleURL} == true`

根據程式語言，對下方清單中的每個連結執行 #fetch (URL)，若程式語言符合 ${fileName} == [<Language> Style Guide]。

Fetch Links

Coding Standards Templates

`"m", "minimal"`

    ```markdown
    ## 1. 簡介
    *   **目的：** 簡要說明為何要建立編碼標準（例如，提升程式碼品質、可維護性與團隊協作）。
    *   **範圍：** 定義此規範適用的語言、專案或模組。

    ## 2. 命名慣例
    *   **變數：** `camelCase`
    *   **函式/方法：** `PascalCase` 或 `camelCase`。
    *   **類別/結構：** `PascalCase`。
    *   **常數：** `UPPER_SNAKE_CASE`。

    ## 3. 格式化與風格
    *   **縮排：** 每個縮排層級使用 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();
        }
        ```

    ### 空格

    - 關鍵字後加一個空格：`if (x)`，而非 `if(x)`
    - 頂層函式之間留一個空行

    ## 4. 註解與文件

    - 解釋*為什麼*，而非*做什麼*，除非意圖不明確。
    - 隨著程式碼變更，保持註解更新。
    - 公開函式應包含用途與參數的簡短說明。

    建議的標籤：

        ```text
        TODO: 後續工作
        FIXME: 已知的不正確行為
        NOTE: 非顯而易見的設計決策
        ```

    ## 5. 錯誤處理

    - 明確處理錯誤情況。
    - 避免靜默失敗；應回傳錯誤或適當記錄。
    - 在失敗回傳前清理資源（檔案、記憶體、控制代碼）。

    ## 6. 提交與審查實務

    ### 提交
    - 每次提交只做一個邏輯變更。
    - 撰寫清晰的提交訊息：

        ```text
        簡短摘要（最多約 50 字元）
        可選的較長說明，解釋背景與理由。
        ```

    ### 審查
    - 保持拉取請求（Pull Request）規模合理。
    - 在審查討論中保持尊重與建設性。
    - 處理要求的變更，或若不同意則說明理由。

    ## 7. 測試

    - 為新功能撰寫測試。
    - 測試應具有確定性（沒有隨機性，除非有種子）。
    - 偏好可讀的測試案例，而非複雜的測試抽象。

    ## 8. 本指南的變更

    風格會演進。
    透過開啟議題或提交更新此文件的修補程式來提出改進建議。
    ```

您可能也喜歡

ponytail

79Kcode-generation

強制使用最懶惰但實際可行的解決方案，最簡單、最短、最精簡。引導一位看過一切的資深開發者：質疑任務是否需要存在（YAGNI），優先使用標準函式庫而非自訂程式碼，原生平台功能而非依賴套件，一行程式碼而非五十行。支援強度等級：lite、full（預設）、ultra。適用於任何程式碼任務：撰寫、新增、重構、修正、審查或設計程式碼，以及選擇函式庫或依賴套件。當使用者說「ponytail」、「be lazy」、「lazy mode」、「simplest solution」、「minimal solution」、「yagni」、「do less」或「shortest path」，或抱怨過度工程、臃腫、樣板程式碼或不必要的依賴時，也應使用。請勿用於非程式碼請求（一般知識、散文、翻譯、摘要、食譜）。

dietrichgebert

獲取

golang-dependency-injection

2.3Kcode-generation

Golang 依賴注入（DI）的完整指南。涵蓋為何 DI 重要（可測試性、鬆散耦合、關注點分離、生命週期管理）、手動建構子注入，以及 DI 函式庫比較（google/wire、uber-go/dig、uber-go/fx、samber/do）。在設計服務架構、設定依賴注入、重構緊耦合程式碼、管理單例或服務工廠，或使用者詢問控制反轉、服務容器、Go 中的依賴連接時，使用此技能。如需特定 DI 函式庫，請參閱 `samber/cc-skills-golang@golang-google-wire`、`samber/cc-skills-golang@golang-uber-dig`、`samber/cc-skills-golang@golang-uber-fx` 或 `samber/cc-skills-golang@golang-samber-do` 技能。

samber

獲取

weather

383Kcode-generation

Current weather and forecasts with web_fetch, falling back to wttr.in curl for locations, rain, temperature, travel planning.

steipete

獲取

繼續探索

瀏覽 code-generation 熱門 Skills 最近更新

write-coding-standards-from-file

相關技能

從檔案撰寫編碼標準

規則與設定

設定變數

作為提示詞參數的設定變數

提示詞參數

必要與選用參數

Variable and Parameter Configuration Conditions

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

${addToREADME} == true

${addToREADMEInsertions} == "atBegin"

${addToREADMEInsertions} == "middle"

${addToREADMEInsertions} == "beforeEnd"

${addToREADMEInsertions} == "bestFitUsingContext"

${addStandardsTest} == true

${createNewFile} == true

${fetchStyleURL} == true

${findInconsistencies} == true

${fixInconsistencies} == true

typeof ${newFileName} == "string"

typeof ${newFileName} != "string"

${outputSpecToPrompt} == true

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

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

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

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

if ${fetchStyleURL} == true