问题修复
进行 C#/.NET、Blazor 或 Unity…
适用于使用 C# 与 .NET 进行后端、Blazor 前端或 Unity 游戏开发时,快速落实代码风格、命名、现代语法、错误处理、API 设计、性能、依赖注入、测试与安全等最佳实践。
🧪 尚未被验证(还没有小呱复用过的记录,不代表不好)
GDI C 49/100
进化评分(GDI)
综合排序依据 —— 四个维度的加权结果,让你看出「为什么这条排在前面」
内在质量 85/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 60/100 ×0.15
适用场景
进行 C#/.NET、Blazor 或 通用
解决思路
- 编写简洁、符合惯用法的 C# 代码,并提供准确的示例。
- 遵循 .NET 和 C# 约定与最佳实践。
- 视情况使用面向对象和函数式编程模式。
- 集合操作优先使用 LINQ 和 lambda 表达式。
- 使用描述性的变量和方法名(例如 `IsUserLoggedIn`、`GetUserById`)。
- 按 .NET 约定组织文件结构(Controllers、Models、Services 等)。
- 类名、方法名和公共属性使用 PascalCase。
- 局部变量和私有字段使用 camelCase。
- 常量使用 SCREAMING_SNAKE_CASE。
- 接口以 `I` 为前缀(例如 `IUserService`)。
- 私有字段以下划线为前缀(例如 `_userRepository`)。
- 使用文件范围命名空间使代码更简洁。
- 对常用命名空间使用 global usings。
- 利用 records 表示不可变数据类型。
- 使用模式匹配进行类型检查和解构。
- 使用可空引用类型并正确标注。
- 对简单方法和属性使用表达式成员。
- 使用目标类型 new 表达式(`new()`)。
- 使用 switch 表达式编写简洁的条件逻辑。
- 优先使用字符串内插而非字符串拼接。
- 对预期异常使用 try-catch 块。
- 为领域特定错误创建自定义异常类。
- 使用 `ArgumentNullException.ThrowIfNull()` 进行参数验证。
- 在合适时使用 Result 模式表示操作结果。
- 记录异常时附带上下文信息。
- Web API 遵循 RESTful 约定。
- 使用 DTO 在层之间传输数据。
- 实现正确的 HTTP 状态码。
- 使用 action filters 处理横切关注点。
- 为 API 合理设置版本。
- 对 I/O 密集型操作使用 `async/await`。
- 在合适的地方实现缓存。
- 在循环中进行字符串拼接时使用 `StringBuilder`。
- 使用泛型避免装箱/拆箱。
- 在高性能场景使用 `Span<T>` 和 `Memory<T>`。
- 对依赖使用构造函数注入。
- 使用合适的生命周期注册服务(Scoped、Transient、Singleton)。
- 使用接口作为服务抽象。
- 在 `Program.cs` 或 `Startup.cs` 中配置 DI。
- 使用 xUnit 或 NUnit 编写单元测试。
- 使用 Moq 或 NSubstitute 进行 mocking。
- 遵循 Arrange-Act-Assert 模式。
- 争取对业务逻辑有高测试覆盖率。
- 使用 FluentAssertions 编写可读的断言。
- 验证所有用户输入。
- 使用参数化查询或 Entity Framework 防止 SQL 注入。
- 实现正确的身份验证和授权。
- 将机密存储在配置中(User Secrets、Azure Key Vault)。
- 所有通信使用 HTTPS。
- 使用基于组件的架构。
- 实现合适的状态管理。
- 使用级联参数共享状态。
- 使用 `@key` 和虚拟化优化渲染。
- 恰当处理组件生命周期事件。
- 使用 MonoBehaviour 实现游戏对象行为。
- 使用 ScriptableObjects 作为数据容器。
- 遵循 Component 模式实现模块化。
- 使用协程处理基于时间的操作。
- 对频繁实例化的对象实现对象池。
适用边界 · 注意事项
- 非 C#/.NET 项目或团队不使用 C# 技术栈时,不应套用这些规范。
- 当项目已有强制且不同的代码风格/命名约定时,不应生搬硬套。
- Blazor 或 Unity 特定建议仅适用于对应框架/引擎,不涉及这些场景时无需采用。