编写或评审 Kotlin 代码时，用统一规范提升可维护性…

适用于 Kotlin 项目的日常开发、代码评审和重构，需要统一命名、函数/类设计、数据处理、异常处理与测试规范时。

适用场景

解决思路

1. 通用原则：所有代码和文档使用英文。
2. 通用原则：始终显式声明每个变量和函数的类型。
3. 通用原则：避免 `any` 类型；改为创建必要的类型。
4. 通用原则：函数体内不要留空行。
5. 命名规范：类、接口、枚举使用 PascalCase。
6. 命名规范：变量、函数、方法、参数使用 camelCase。
7. 命名规范：环境变量、常量使用 UPPERCASE。
8. 命名规范：文件和目录使用 underscores_case。
9. 命名指南：每个函数以动词开头，如 get、set、create、update、delete 等。
10. 命名指南：优先使用完整单词而非缩写。
11. 命名指南：允许的缩写为 API、URL、循环变量 i/j、err、ctx、req/res/next。
12. 命名指南：避免魔法数字；改为定义常量。
13. 命名指南：布尔变量使用前缀，如 `isLoading`、`hasError`、`canDelete`。
14. 函数设计：保持函数少于 20 条指令。
15. 函数设计：每个函数只承担单一职责。
16. 函数设计：当复杂度增加时，将逻辑抽取到工具函数。
17. 函数命名：使用描述动作的基于动词的命名。
18. 函数命名：返回布尔值的函数以 `is`、`has` 或 `can` 为前缀。
19. 函数命名：void 函数以动作动词为前缀，如 `execute`、`save`、`send`。
20. 减少嵌套：使用提前返回来优先处理边界情况。
21. 减少嵌套：将嵌套逻辑抽取到独立函数。
22. 减少嵌套：使用高阶函数（map、filter、reduce）来减少循环。
23. 减少嵌套：简单操作优先使用箭头函数；否则使用命名函数。
24. 参数设计：使用默认参数代替 null 检查。
25. 参数设计：当函数有多个参数时，按 RO-RO 模式将它们合并到对象中。
26. 参数设计：保持参数列表简短，最多 3-4 个参数。
27. 数据处理：使用 data classes 表示数据结构。
28. 数据处理：当原始类型表示领域概念时，将其封装到复合类型中。
29. 数据处理：在 data classes 内部验证数据。
30. 不可变性：数据优先不可变。
31. 不可变性：对不会变化的变量使用 `val`。
32. 不可变性：尽可能使用不可变集合。
33. 不可变性：创建新实例而不是修改现有实例。
34. 类设计：保持类少于 200 条指令。
35. 类设计：限制公开方法少于 10 个。
36. 类设计：限制属性少于 10 个。
37. 类设计：遵循 SOLID 原则。
38. 类设计：优先组合而非继承。
39. 类设计：使用接口进行抽象。
40. 类设计：保持类专注于单一职责。
41. 异常处理：异常仅用于真正意外的错误。
42. 异常处理：不要用异常控制流程。
43. 异常处理：仅在修复可预见的问题时捕获异常。
44. 异常处理：仅在重新抛出前添加上下文时捕获异常。
45. 异常处理：为领域特定错误创建自定义异常类型。
46. 异常处理：包含有意义的错误消息。
47. 异常处理：在适当级别记录异常。
48. 测试：遵循 Arrange-Act-Assert 约定。
49. 测试：为所有公开函数编写单元测试。
50. 测试：对依赖使用测试替身（mocks、stubs、fakes）。
51. 测试：用描述性名称命名测试以记录行为。
52. 测试：遵循 Given-When-Then 约定。
53. 测试：测试面向用户的行为和场景。
54. 测试：保持测试独立且可重复。
55. 代码组织：将相关功能分组在一起。
56. 代码组织：保持文件聚焦且内聚。
57. 代码组织：使用 packages/modules 按功能或层次组织代码。
58. 代码组织：在项目中保持一致的文件结构。

适用边界 · 注意事项

• 不适用于非 Kotlin 项目或必须遵循既有非 Kotlin 代码规范的场景。
• 不适用于一次性原型、脚本或探索性代码，此时强制函数/类大小与完整测试可能成本过高。
• 不适用于团队已有明确且冲突的 Kotlin 风格指南，应优先遵循项目现有约定。