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，否则继续到 ${newFileName} 的下一个文件名。
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`

根据编程语言，对于下面列表中的每个链接，如果编程语言是 ${fileName} == [<Language> Style Guide]，则运行 #fetch (URL)。

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 个字符）
        可选的更长的上下文和理由说明。
        ```

    ### 审查
    - 保持拉取请求合理的小。
    - 在审查讨论中保持尊重和建设性。
    - 处理请求的更改，或解释你不同意的理由。

    ## 7. 测试

    - 为新功能编写测试。
    - 测试应是确定性的（没有随机性，除非有种子）。
    - 优先选择可读的测试用例，而不是复杂的测试抽象。

    ## 8. 对本指南的更改

    风格会演变。
    通过提交问题或发送补丁来更新本文档，提出改进建议。
    ```

你可能还喜欢

modern-javascript-patterns

38Kcode-generation

Master ES6+ features including async/await, destructuring, spread operators, arrow functions, promises, modules, iterators, generators, and functional programming patterns for writing clean, efficient JavaScript code. Use when refactoring legacy code, implementing modern patterns, or optimizing JavaScript applications.

wshobson

获取

ponytail

79Kcode-generation

强制采用实际可行的最懒解决方案，最简单、最短、最精简。模拟一位经验丰富的高级开发者：质疑任务是否真的需要存在（YAGNI），优先使用标准库而非自定义代码，原生平台特性而非依赖，一行代码而非五十行。支持强度级别：lite、full（默认）、ultra。适用于任何编码任务：编写、添加、重构、修复、审查或设计代码，以及选择库或依赖项。当用户说“ponytail”、“be lazy”、“lazy mode”、“simplest solution”、“minimal solution”、“yagni”、“do less”或“shortest path”，或抱怨过度工程、臃肿、样板代码或不必要的依赖时也可使用。请勿用于非编码请求（通用知识、散文、翻译、摘要、食谱）。

dietrichgebert

获取

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

相关 Skills

从文件编写编码规范

规则与配置

配置变量

作为提示参数的配置变量

提示参数

必需和可选参数

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