编辑器规范

代码风格

1.1 代码格式化

• 使用 Prettier 进行代码格式化
• 使用 ESLint 进行代码检查

1.2 代码注释

• 文件注释：在文件开头添加文件注释，包括文件功能、作者、创建日期等信息
• 函数注释：在函数定义前添加函数注释，包括函数功能、参数、返回值等信息
• 变量注释：在变量定义前添加变量注释，包括变量功能、类型等信息

1.3 代码命名

• 变量命名：使用驼峰命名法，如 userName、userAge
• 函数命名：使用驼峰命名法，如 getUserInfo、setUserInfo
• 常量命名：使用全大写字母，单词之间用下划线分隔，如 MAX_USER_COUNT
• 类命名：使用帕斯卡命名法，如 UserInfo、UserManager

1.4 代码结构

• 每个文件只包含一个类或模块
• 每个函数只做一件事情
• 每个模块只做一件事情
• 每个类只做一件事情

1.5 代码复用

• 尽量使用函数、类、模块等来复用代码
• 尽量避免重复代码
• 尽量使用继承、组合等设计模式来复用代码

代码提交

2.1 提交规范

• 使用 git 进行代码管理
• 使用 git commit 提交代码
• 提交信息格式：<type>: <subject>，其中 <type> 是提交类型，<subject> 是提交主题
• 提交类型包括：feat、fix、docs、style、refactor、perf、test、chore

2.2 提交信息

• 提交信息应简洁明了，描述清楚提交的内容
• 提交信息应遵循提交规范，使用正确的提交类型和主题
• 提交信息应包含必要的上下文信息，如修改的文件、修改的功能等

代码审查

3.1 审查流程

• 代码审查应在代码提交后进行
• 代码审查应由其他开发者进行
• 代码审查应包括代码风格、代码逻辑、代码安全等方面

3.2 审查标准

• 代码风格应符合规范
• 代码逻辑应清晰、简洁、高效
• 代码安全应考虑潜在的安全风险
• 代码应遵循最佳实践

3.3 审查反馈

• 审查反馈应包括代码中的问题、建议和改进意见
• 审查反馈应明确指出问题的位置和原因
• 审查反馈应提供改进建议和解决方案

代码版本管理

4.1 版本控制

• 使用 git 进行版本控制
• 使用 git branch 创建分支
• 使用 git merge 合并分支
• 使用 git tag 创建标签

4.2 版本发布

• 每次发布前，应创建一个新的标签
• 每次发布前，应进行代码审查和测试
• 每次发布前，应更新文档和版本号

代码部署

5.1 部署流程

• 使用 git 进行代码部署
• 使用 git push 推送代码到远程仓库
• 使用 git pull 拉取代码到本地仓库
• 使用 git checkout 切换分支

5.2 部署环境

• 部署环境应与开发环境一致
• 部署环境应与测试环境一致
• 部署环境应与生产环境一致

5.3 部署策略

• 部署策略应考虑代码的稳定性和安全性
• 部署策略应考虑代码的版本控制和回滚
• 部署策略应考虑代码的监控和报警

代码维护

6.1 代码维护

• 代码维护应包括代码的更新、修复和优化
• 代码维护应包括代码的文档和注释
• 代码维护应包括代码的测试和验证

6.2 代码优化

• 代码优化应包括代码的性能优化
• 代码优化应包括代码的内存优化
• 代码优化应包括代码的代码优化

6.3 代码文档

• 代码文档应包括代码的说明、使用和示例
• 代码文档应包括代码的接口和参数
• 代码文档应包括代码的版本和更新记录

代码规范

7.1 代码规范

• 代码规范应包括代码的命名、注释和格式
• 代码规范应包括代码的编码和注释规范
• 代码规范应包括代码的代码风格和代码规范

7.2 代码命名

• 代码命名应遵循驼峰命名法
• 代码命名应遵循语义化命名
• 代码命名应遵循简洁明了的命名

7.3 代码注释

• 代码注释应遵循代码规范
• 代码注释应包括代码的说明、使用和示例
• 代码注释应包括代码的接口和参数

7.4 代码格式

• 代码格式应遵循代码规范
• 代码格式应包括代码的缩进、空格和换行
• 代码格式应包括代码的代码风格和代码规范