|
1 | 1 | --- |
2 | | -type: "always_apply" |
| 2 | +alwaysApply: true |
3 | 3 | --- |
4 | 4 |
|
5 | | - |
6 | | -所有语言必须遵守通用规则,特定语言必须在通用规则基础之上遵循特定语言的规则 |
7 | | - |
8 | | -# 通用标准 |
9 | | - |
10 | | -**强制规则** |
11 | | - |
12 | | -1. 始终使用**简体中文**回复,即使用户输入大量英文提示,也应返回简体中文 |
13 | | -2. 禁止编写任何供用户使用的示例代码,即使需要临时测试,任务完成后也必须立即删除 |
14 | | -3. 严禁通过简化问题来解决问题 |
15 | | -4. 严禁通过降级依赖版本、减少测试断言、使用恒定测试条件等来解决编译错误以及运行时错误 |
16 | | -5. 严禁忽略异常或任何隐藏异常的行为 |
17 | | -6. 严禁在代码中暴露 API 密钥、密码和令牌 |
18 | | -7. 应当积极按照规则来重构修复上下文中出现的代码 |
19 | | -8. 应积极使用日志完善记录,主动补充缺失的日志 |
20 | | -9. 允许在单元测试调试期间添加日志以协助解决问题 |
21 | | -10. 必须最大化使用 `early return` 技术来减少代码嵌套层级 |
22 | | -11. 严禁在对话或任务完成后生成总结文档文件和其他不必要的操作 |
23 | | -12. 严禁出现以下令人作呕且腐朽不堪的词汇出现在任何除开第三方库调用的任何地方 |
24 | | -+ `util`, `utils` |
25 | | -+ `helper`, `helpers` |
26 | | -+ `tool`, `tools` |
27 | | - |
28 | | -13. 严禁使用 `@Suppress`/`// @ts-ignore` 等注解压制警告 |
29 | | - |
30 | | -**渐进式开发方法论** |
31 | | - |
32 | | -- 采用测试驱动开发结合渐进式开发方法 |
33 | | -- **Baby Steps开发**:每次只编写少量代码,立即进行单元测试验证 |
34 | | -- **快速反馈循环**:开发一点测试一点,绝不一次性编写大量代码 |
35 | | -- **逐个验证原则**:为多个代码编写单元测试时,一个个编写一个个验证,避免批量编写后统一验证 |
36 | | -- **风险最小化**:通过频繁的小幅度验证确保代码质量,避免错误累积 |
37 | | -- **嵌套测试组织**:使用合适的分组,避免根级别大量独立测试方法 |
38 | | -- 严禁出现没有断言的测试方法,发现应该立即补全断言 |
39 | | - |
40 | | -**日志规范** |
41 | | - |
42 | | -- 在没有日志的情况下,应当多使用日志记录,以协助线上问题排查解决以及获取更多上下文信息 |
43 | | -- 在排查问题时,可向源代码中添加更多日志,以获取更详细的上下文信息 |
44 | | -- 日志应当只使用英文进行记录,如发现其他语言应当立即修正为英文 |
45 | | -- 重点记录第三方库调用和外部API的详细日志,包括请求参数、响应结果、耗时等信息 |
46 | | -- 使用结构化日志格式:`log.info("API call completed - endpoint: {}, status: {}, duration: {}ms", endpoint, status, duration)` |
47 | | -- 记录关键上下文信息:用户ID、请求ID、操作类型、结果状态、异常详情 |
48 | | -- 避免记录敏感信息:密码、API密钥、身份证号、手机号等 |
49 | | -- 在外部调用、数据库操作、文件操作等关键节点记录日志 |
50 | | -- 使用占位符格式避免字符串拼接,保持日志消息简洁明了 |
51 | | -- 合理使用日志级别,避免生产环境输出过多DEBUG日志 |
52 | | - |
53 | | -**注释规则** |
54 | | - |
55 | | -- 文档注释:必须使用英文注释 |
56 | | -- 代码内部注释:必须使用中文注释 |
57 | | -- 严禁使用行尾注释 |
58 | | - |
59 | | -**测试组织最佳实践:** |
60 | | - |
61 | | -- 每个被测试类/函数/变量/方法创建主要分组 |
62 | | -- 按场景细分:正常用例、异常用例、边界用例 |
63 | | - + 示例kotlin:`@Nested inner class CreateUser { @Test fun should_create_successfully() {} }` |
64 | | - |
65 | | -**代码风格** |
66 | | - |
67 | | -- 代码缩进:使用2个空格缩进 |
68 | | -- 代码换行:每个文件必须保留行尾换行符 |
69 | | -- 文件编码:必须使用UTF-8编码 |
70 | | -- 文件换行符:必须使用LF换行符 |
71 | | -- 行长度:每行字符长度不能超过160个字符 |
72 | | -- 配置参考:可参考项目根目录下的 `.editorconfig` 配置 |
73 | | - |
74 | | -# 特定语言约定 |
75 | | - |
76 | | -**SQL 规则** |
77 | | - |
78 | | -- 严禁在 SQL 中使用任何注释 |
79 | | -- 检查现有查询是否使用参数化 |
80 | | -- 统一使用 snake_case 命名,即使是出现在其他语言中的字符串 |
81 | | - |
82 | | -**JVM 规则** |
83 | | - |
84 | | -1. 严禁在测试代码中使用 `@DisplayName` 注解 |
85 | | -2. spring/quarkus 中严禁使用特定框架的注解,例如:`@Autowired`必须使用 `@Resource` 替代 |
86 | | -3. 尽可能使用项目内JDK版本能使用的最大限度的新特性 |
87 | | -4. 禁止在单元测试中使用 `@DisplayName` 注解 |
88 | | -5. 单元测试方法名称使用英文命名,以及下划线分割 |
89 | | -6. 禁止单元测试方法名以 `test_`、`should_` 开头 |
90 | | -7. 记录日志时,格式为 `log.info("message param1: {}, param2{}")` 这种格式 |
91 | | -8. 禁止记录详细的敏感信息,例如:密码、身份证号、APIKEY、手机号等 |
92 | | - |
93 | | -**Java 规则** |
94 | | - |
95 | | -所有JVM平台的编程语言:java、kotlin、groovy、scala 均需遵守以下原则 |
96 | | - |
97 | | -1. 可使用 `import xxx.*` 导入来减少代码量,后续交由IDE进行处理 |
98 | | -2. 尽可能使用jdk的新特性 |
99 | | -3. 声明变量应尽量使用 `final var` |
100 | | -4. 积极使用 lambda |
101 | | -5. 严禁使用 `System.out.println` 记录输出 |
102 | | - |
103 | | -**Kotlin 规则** |
104 | | - |
105 | | -1. 优先使用val声明不可变变量 |
106 | | -2. 避免!!操作符,使用?.或let{} |
107 | | -3. 数据类替代多参数函数 |
108 | | -4. 严禁使用 `println` 记录输出 |
109 | | -5. 严禁在单元测试中使用 `mockito`,而是使用 `mockk` |
110 | | -6. 扩展方法与纯函数应分开,不应在同一文件中 |
111 | | -+ 扩展函数文件命名规范:使用 `*Extensions.kt` 后缀 |
112 | | -+ 纯函数文件命名规范:使用 `*Functions.kt` 后缀 |
113 | | - |
114 | | -**TypeScript规则** |
115 | | - |
116 | | -- TypeScript: 启用strict模式,避免any类型 |
117 | | - |
118 | | -**SCSS 规则** |
119 | | - |
120 | | -- 禁止使用 `@import`,使用 `@use` 代替 |
| 5 | +**Mandatory Rules** |
| 6 | + |
| 7 | +1. Always respond in **Simplified Chinese**, even if the user inputs extensive English prompts, responses should still be in Simplified Chinese |
| 8 | +2. Prohibit writing any sample code for user consumption, even if needed for temporary testing, it must be deleted immediately after task completion |
| 9 | +3. Strictly prohibit solving problems by simplifying them |
| 10 | +4. Strictly prohibit solving compilation errors and runtime errors by downgrading dependency versions, reducing test assertions, using constant test conditions, etc. |
| 11 | +5. Strictly prohibit ignoring exceptions or any behavior that hides exceptions |
| 12 | +6. Strictly prohibit exposing API keys, passwords, and tokens in code |
| 13 | +7. Should actively refactor and fix code appearing in context according to rules |
| 14 | +8. Should actively use logging to improve records, proactively supplement missing logs |
| 15 | +9. Allow adding logs during unit test debugging to assist in problem resolution |
| 16 | +10. Must maximize the use of `early return` technique to reduce code nesting levels |
| 17 | +11. Strictly prohibit generating summary documentation files and other unnecessary operations after dialogue or task completion |
| 18 | +12. Strictly prohibit the appearance of the following disgusting and decadent terms anywhere except in third-party library calls |
| 19 | + + `util`, `utils` |
| 20 | + + `helper`, `helpers` |
| 21 | + + `tool`, `tools` |
| 22 | + |
| 23 | +13. Strictly prohibit using `@Suppress`/`// @ts-ignore` and other annotations to suppress warnings |
| 24 | + |
| 25 | +**Progressive Development Methodology** |
| 26 | + |
| 27 | +- Adopt test-driven development combined with progressive development approach |
| 28 | +- **Baby Steps Development**: Write only small amounts of code each time, immediately verify with unit tests |
| 29 | +- **Rapid Feedback Loop**: Develop a bit and test a bit, never write large amounts of code at once |
| 30 | +- **Individual Verification Principle**: When writing unit tests for multiple pieces of code, write and verify one by one, avoid batch writing followed by unified verification |
| 31 | +- **Risk Minimization**: Ensure code quality through frequent small-scale verification, avoid error accumulation |
| 32 | +- **Nested Test Organization**: Use appropriate grouping, avoid large numbers of independent test methods at root level |
| 33 | +- Strictly prohibit test methods without assertions, immediately supplement assertions when found |
| 34 | + |
| 35 | +**Logging Standards** |
| 36 | + |
| 37 | +- When there are no logs, should use more logging to assist in online problem troubleshooting and obtaining more contextual information |
| 38 | +- When troubleshooting problems, can add more logs to source code to obtain more detailed contextual information |
| 39 | +- Logs should only use English for recording, if other languages are found they should be immediately corrected to English |
| 40 | +- Focus on recording detailed logs of third-party library calls and external APIs, including request parameters, response results, duration, etc. |
| 41 | +- Use structured log format: `log.info("API call completed - endpoint: {}, status: {}, duration: {}ms", endpoint, status, duration)` |
| 42 | +- Record key contextual information: user ID, request ID, operation type, result status, exception details |
| 43 | +- Avoid recording sensitive information: passwords, API keys, ID numbers, phone numbers, etc. |
| 44 | +- Record logs at key points such as external calls, database operations, file operations |
| 45 | +- Use placeholder format to avoid string concatenation, keep log messages concise and clear |
| 46 | +- Use log levels appropriately, avoid outputting too many DEBUG logs in production environment |
| 47 | + |
| 48 | +**Comment Rules** |
| 49 | + |
| 50 | +- Documentation comments: Must use English comments |
| 51 | +- Internal code comments: Must use Chinese comments |
| 52 | +- Strictly prohibit using end-of-line comments |
0 commit comments