⚡

代码风格执行器Skill code-style-enforcer

确保代码遵循项目特定的风格约定和模式，这些可能是自动化 linters 可能遗漏的。

前端开发 0 次安装 0 次浏览 更新于 3/3/2026

name: code-style-enforcer description: 代码风格执行器 Analyzes code for style consistency and applies project-specific formatting conventions beyond what linters catch. Use when reviewing code, ensuring style consistency, or when user requests code style improvements. allowed-tools: Read, Grep, Glob, Edit

代码风格执行器

This skill ensures code follows project-specific style conventions and patterns that automated linters may miss.

何时使用此技能

  • 用户请求代码风格审查或改进
  • 确保代码库的一致性
  • 引入新代码或贡献者时
  • 提交前代码审查
  • 用户提到“风格”、“一致性”、“格式化”或“约定”

指南

1. 检测项目风格指南

Look for style configuration files:

JavaScript/TypeScript:

  • .eslintrc.* - ESLint 配置
  • .prettierrc.* - Prettier 配置
  • tsconfig.json - TypeScript 编译器选项
  • .editorconfig - 编辑器配置

Python:

  • .pylintrc, pylint.cfg - Pylint
  • pyproject.toml - Black, isort 配置
  • .flake8 - Flake8 配置
  • setup.cfg - 各种工具配置

Ruby:

  • .rubocop.yml - RuboCop 配置

Go:

  • go.fmt enforced (standard)
  • .golangci.yml - GolangCI-Lint

Java:

  • checkstyle.xml - Checkstyle
  • .editorconfig

General:

  • CONTRIBUTING.md - 贡献指南
  • STYLE_GUIDE.md - 项目风格指南
  • .editorconfig - 跨编辑器设置

Use Glob to find these files and Read to understand the project’s style preferences.

2. 分析现有代码模式

Sample existing code to understand implicit conventions:

文件组织:

  • 目录结构模式
  • 文件命名约定 (camelCase, kebab-case, snake_case)
  • 导入/导出组织

代码结构:

  • 类/函数排序
  • 公共与私有方法的放置
  • 常量/变量声明位置

格式化:

  • 缩进 (空格 vs 制表符, 大小)
  • 行长度限制
  • 空行使用
  • 注释风格

命名:

  • 变量命名 (camelCase, snake_case)
  • 类命名 (PascalCase, 首字母大写)
  • 常量命名 (UPPER_CASE, 等)
  • 文件命名模式

Use Grep to find common patterns across similar files.

3. 超出 Linters: 检查模式

Focus on style issues that automated tools often miss:

命名一致性:

  • 布尔变量: is, has, should 前缀
  • 事件处理器: handle*, on* 模式
  • Getter/setter: get*, set* 一致性
  • 集合命名: 复数 vs 单数
  • 缩写词: 一致的大写

代码组织:

  • 相关函数分组在一起
  • 跨模块一致的文件结构
  • 逻辑排序 (公共在前，私有在后，等)
  • 分离关注点

注释和文档:

  • JSDoc/docstring 完整性
  • 注释风格一致性
  • TODO/FIXME 格式
  • 内联 vs 块注释

导入/导出模式:

  • 导入排序 (外部，内部，相对)
  • 命名 vs 默认导出
  • 析构一致性
  • 别名模式

错误处理:

  • 一致的错误消息格式
  • 错误类使用
  • Try/catch 模式
  • 日志格式

类型使用 (TypeScript/类型语言):

  • 显式 vs 推断类型
  • interface vs type 偏好
  • 泛型命名 (T, K, V vs 描述性)
  • Null/undefined 处理

4. 识别常见反模式

Flag code smells and anti-patterns:

魔法数字:

// 坏
if (status === 200) { }

// 好
const HTTP_OK = 200;
if (status === HTTP_OK) { }

不一致的空检查:

// 不一致
if (user === null) { }
if (!data) { }
if (typeof result === 'undefined') { }

// 一致
if (user === null) { }
if (data === null) { }
if (result === undefined) { }

嵌套三元运算符:

// 难以阅读
const value = a ? b ? c : d : e;

// 更好
let value;
if (a) {
  value = b ? c : d;
} else {
  value = e;
}

长参数列表:

# 难以维护
def create_user(name, email, age, address, phone, ...):

# 更好
def create_user(user_data: UserData):

5. 检查项目特定约定

Look for patterns unique to this project:

  • 特定领域的自定义命名 (例如，“repo” vs “repository”)
  • 常用任务的首选库
  • 架构模式 (MVC, 服务层, 等)
  • 测试文件命名和结构
  • 配置模式

Read CONTRIBUTING.md, README.md, or similar docs for explicit guidelines.

6. 生成风格建议

For each issue, provide:

当前代码:

function getData(id) {
  const d = fetch('/api/users/' + id);
  return d;
}

问题:

  • 命名不一致 (getData vs 其他函数使用 fetch*)
  • 单字母变量名 (d)
  • 字符串连接而不是模板字面量

推荐:

function fetchUser(id) {
  const userData = fetch(`/api/users/${id}`);
  return userData;
}

7. 优先级问题

Order by impact:

高优先级 (一致性):

  • 相似函数的命名不一致
  • 混合缩进或格式化
  • 不一致的错误处理

中优先级 (可读性):

  • 魔法数字/字符串
  • 不清晰的变量名
  • 缺少文档

低优先级 (锦上添花):

  • 注释格式化
  • 导入排序
  • 额外的空行

8. 建议自动化工具

Recommend tools to enforce styles:

JavaScript/TypeScript:

npm install --save-dev prettier eslint
npx prettier --write .
npx eslint --fix .

Python:

pip install black isort flake8
black .
isort .

Go:

go fmt ./...
golangci-lint run

Ruby:

gem install rubocop
rubocop -a

9. 创建或更新 EditorConfig

Suggest .editorconfig if missing:

root = true

[*]
charset = utf-8
end_of_line = lf
insert_final_newline = true
trim_trailing_whitespace = true

[*.{js,ts,jsx,tsx}]
indent_style = space
indent_size = 2

[*.py]
indent_style = space
indent_size = 4

[*.go]
indent_style = tab

10. 风格审查清单

When reviewing code for style:

  • [ ] 命名遵循项目约定
  • [ ] 缩进和格式化一致
  • [ ] 导入组织得当
  • [ ] 需要的地方有注释，不过多
  • [ ] 没有魔法数字或字符串
  • [ ] 错误处理一致
  • [ ] 文件组织与项目结构匹配
  • [ ] 没有明显的代码异味
  • [ ] 类型注释一致 (如果适用)
  • [ ] 测试遵循测试约定

最佳实践

  1. 一致性优于完美: 即使不理想，也遵循现有模式
  2. 记录决策: 为模糊情况添加风格指南
  3. 尽可能自动化: 使用 Prettier, Black, gofmt 等
  4. 务实: 不要仅仅为了风格而重构工作代码
  5. 团队共识: 对重要的风格达成一致
  6. 逐步改进: 在触及的文件中修复风格，而不是一次性全部
  7. 可读性第一: 风格服务于可读性，反之则不是

常见风格冲突

制表符 vs 空格

  • 检查 .editorconfig 或现有文件
  • 如果不确定，使用项目多数

引号风格 (单引号 vs 双引号)

  • JavaScript: 单引号 (') 常见
  • Python: 两者均可，保持一致
  • Go: 总是双引号 (")
  • 如果有 linter 配置，遵循之

分号 (JavaScript)

  • 检查现有代码多数
  • 如果混合，建议使用 Prettier 强制执行

行长度

  • 常见限制: 80, 100, 120 字符
  • 检查 linter 配置或 .editorconfig

导入排序

  • 通常: 标准库，外部，内部，相对
  • 使用自动化工具 (isort, 组织导入)

支持文件

  • reference/style-guides.md: 链接到流行风格指南
  • examples/before-after.md: 显示改进的代码示例