🚀 快速安装
复制以下命令并运行,立即安装此 Skill:
npx @anthropic-ai/skills install github/awesome-copilot/write-coding-standards-from-file
💡 提示:需要 Node.js 和 NPM
从文件编写编码标准
使用一个或多个文件的现有语法来为项目建立标准和风格指南。如果传递了多个文件或一个文件夹,则遍历每个文件或文件夹中的文件,将文件数据追加到临时内存或文件中,然后完成后使用临时数据作为单个实例;就像它是用于制定标准和风格指南的基准文件名一样。
规则与配置
以下是一组准配置 布尔值 和 字符串数组 变量。处理 true 或其他值的条件在二级标题 ## 变量和参数配置条件 下。
提示的参数有文本定义。有一个必需参数 ${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"]]。 - 从提示文件底部二级标题
## 编码标准模板下的两个示例模板中选择一个,或使用更合适的其他组合。 - 如果是 custom,则根据请求应用。
- 可能的值是
作为提示参数的配置变量
如果任何变量名称按原样传递给提示,或者作为相似但清晰相关的文本值传递,则用传递给提示的值覆盖默认变量值。
提示参数
- fileName = 将被分析的文件名,分析内容包括:缩进、变量命名、注释、条件过程、函数过程以及该文件编程语言的其他语法相关数据。
- folderName = 将被用于从多个文件中提取数据到一个聚合数据集的文件夹名,该数据集将被分析,分析内容包括:缩进、变量命名、注释、条件过程、函数过程以及这些文件编程语言的其他语法相关数据。
- instructions = 将为特殊情况提供的额外指令、规则和过程。
- [configVariableAsParameter] = 如果传递,将覆盖配置变量的默认状态。示例:
- useTemplate = 如果传递,将覆盖配置
${useTemplate}的默认值。值为[["v", "verbose"], ["m", "minimal"], ["b", "best fit"]]。
- useTemplate = 如果传递,将覆盖配置
必需和可选参数
- fileName – 必需
- folderName – 可选
- instructions – 可选
- [configVariableAsParameter] – 可选
变量和参数配置条件
${fileName}.长度 > 1 || ${folderName} != undefined
- 如果为真,将
${fixInconsistencies}切换为 false。
${addToREADME} == true
- 将编码标准插入到
README.md中,而不是输出到提示或创建新文件。 - 如果为真,将
${createNewFile}和${outputSpecToPrompt}都切换为 false。
${addToREADMEInsertions} == "atBegin"
- 如果
${addToREADME}为真,则在README.md文件的开头(标题之后)插入编码标准数据。
${addToREADMEInsertions} == "middle"
- 如果
${addToREADME}为真,则在README.md文件的中间插入编码标准数据,更改标准标题以匹配README.md的构成。
${addToREADMEInsertions} == "beforeEnd"
- 如果
${addToREADME}为真,则在README.md文件的末尾插入编码标准数据,在最后一个字符后插入新行,然后在新行上插入数据。
${addToREADMEInsertions} == "bestFitUsingContext"
- 如果
${addToREADME}为真,则根据README.md的构成和数据流的上下文,在README.md文件的最合适行插入编码标准数据。
${addStandardsTest} == true
- 一旦编码标准文件完成,编写一个测试文件以确保传递的文件符合编码标准。
${createNewFile} == true
- 使用
${newFileName}的值或可能的值之一创建一个新文件。 - 如果为真,将
${outputSpecToPrompt}和${addToREADME}都切换为 false。
${fetchStyleURL} == true
- 另外,使用从三级标题
### 获取链接下的链接获取的数据作为创建新文件、提示或README.md的标准、规范和样式数据的上下文。 - 对于
### 获取链接中的每个相关项目,运行#fetch ${项目}。
${findInconsistencies} == true
- 评估与缩进、换行、注释、条件和函数嵌套、字符串的引号包裹(例如
'或")等相关的语法,并进行分类。 - 对每个类别进行计数,如果某个项目与计数的大多数不匹配,则提交到临时内存。
- 根据
${fixInconsistencies}的状态,要么编辑并修复低计数类别以匹配大多数,要么将存储在临时内存中的不一致输出到提示。
${fixInconsistencies} == true
- 使用存储在临时内存中的不一致数据,编辑并修复语法数据的低计数类别,以匹配相应语法数据的大多数。
typeof ${newFileName} == "string"
- 如果明确定义为
string,则使用${newFileName}的值创建一个新文件。
typeof ${newFileName} != "string"
- 如果未明确定义为
string,而是作为object或数组,则通过应用以下规则使用${newFileName}中的值创建一个新文件:- 对于
${newFileName}中的每个文件名,如果文件不存在,则使用该文件名并break,否则继续下一个。
- 对于
${outputSpecToPrompt} == true
- 将编码标准输出到提示,而不是创建文件或添加到 README。
- 如果为真,将
${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} == [<语言> 风格指南]。
获取链接
- 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. 引言
* **目的:** 简要说明为何建立编码标准(例如,为了提高代码质量、可维护性和团队协作)。
* **范围:** 定义此规范适用于哪些语言、项目或模块。
## 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. 命名约定
使用描述性名称。除非众所周知,否则避免使用缩写。
| 项目 | 约定 | 示例 |
|-----------------|------------------------|---------------------|
| 变量 | `小写蛇形` | `buffer_size` |
| 函数 | `小写蛇形()` | `read_file()` |
| 常量 | `大写蛇形` | `MAX_RETRIES` |
| 类型/结构体 | `帕斯卡式` | `FileHeader` |
| 文件名 | `小写蛇形` | `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. 对本指南的更改
风格是会演变的。
通过发起议题或发送更新本文档的补丁来提出改进建议。
```
📄 原始文档
完整文档(英文):
https://skills.sh/github/awesome-copilot/write-coding-standards-from-file
💡 提示:点击上方链接查看 skills.sh 原始英文文档,方便对照翻译。
声明:本站所有文章,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

评论(0)