deslop-simplify-ai-code

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Deslop: Simplify AI Code

Deslop：简化AI生成代码

Expert code simplification focused on clarity, consistency, and maintainability while preserving exact functionality. Analyze code for unnecessary complexity, redundant patterns, and opportunities to make code more readable and idiomatic. Apply project-specific best practices—match existing code style, naming conventions, and patterns already established in the codebase.

专注于在完全保留代码功能的前提下，实现代码的清晰性、一致性和可维护性的专业代码简化方案。分析代码中的不必要复杂度、冗余模式，并寻找机会让代码更具可读性、更符合语言习惯。遵循项目特定的最佳实践——匹配代码库中已有的代码风格、命名规范和模式。

Workflow

工作流程

Understand project context: Review existing code style, patterns, and conventions in the codebase
Get the diff:
```
git diff main...HEAD
```
or
```
git diff main
```
Identify slop patterns in changed lines
Simplify: Remove or refactor each instance to match project idioms
Verify: Ensure functionality unchanged, code aligns with existing style

了解项目上下文：审查代码库中已有的代码风格、模式和规范
获取代码差异：执行
```
git diff main...HEAD
```
或
```
git diff main
```
识别冗余代码模式：在变更代码行中找出冗余模式
简化代码：移除或重构每个冗余实例，使其符合项目的编码惯例
验证：确保代码功能未改变，且与现有代码风格一致

Slop Patterns

冗余代码模式

Comments

注释

Rule: Comments explain WHY, not WHAT.

Remove:

Comments restating what code does:
```
// increment counter
```
above
```
counter++
```
Section dividers:
```
// ========== VALIDATION ==========
```
Redundant docstrings documenting self-evident parameters
"Note:" or "Important:" prefixes that add nothing
Comments explaining language basics

Transform WHAT → WHY:

undefined

规则：注释应解释原因，而非描述内容。

移除以下类型的注释：

重复描述代码功能的注释：例如
```
counter++
```
上方的
```
// increment counter
```
区块分隔符：如
```
// ========== VALIDATION ==========
```
对自明参数的冗余文档字符串
无实际意义的「Note:」或「Important:」前缀
解释编程语言基础的注释

将描述内容的注释转换为解释原因的注释：

undefined

SLOP: describes what

冗余：描述内容

Check if user is active

if user.is_active:

CLEAN: explains why

优化：解释原因

Inactive users can't access billing portal

非活跃用户无法访问账单门户

if user.is_active:

undefined

// SLOP: restates the code // Loop through all items and process each one for item in items: process(item)

// CLEAN: no comment needed, or explain why this approach // Process sequentially - parallel causes rate limit errors for item in items: process(item)

undefined

if user.is_active:

undefined

// 冗余：重复代码内容 // Loop through all items and process each one for item in items: process(item)

// 优化：无需注释，或解释采用该方式的原因 // 按顺序处理 - 并行处理会触发速率限制错误 for item in items: process(item)

undefined

Null/Error Handling

空值/错误处理

Remove redundant checks:

undefined

移除重复检查：

undefined

SLOP: checking what's already guaranteed

冗余：检查已被保证的内容

if user is not None and user is not empty and is_valid_type(user): if user.name is not None and user.name is not empty:

CLEAN: trust the type system or add one meaningful check

优化：信任类型系统或添加一个有意义的检查

if user and user.name:


Simplify excessive try-catch:

if user and user.name:


简化过度的try-catch结构：

SLOP: catch-log-rethrow adds nothing

冗余：捕获-日志-重抛无实际作用

try: do_thing() catch error: log("Error doing thing:", error) throw error

CLEAN: let it propagate or handle meaningfully

优化：让错误自行传播或进行有意义的处理

do_thing()

undefined

do_thing()

undefined

Abstractions

抽象层

Flatten unnecessary layers:

Single-use helper functions that obscure rather than clarify
Wrapper classes around simple operations
"Manager", "Handler", "Service" suffixes on thin wrappers
Config objects for 1-2 values

扁平化不必要的层级：

单一用途的辅助函数（反而模糊了代码逻辑）
简单操作的包装类
单薄包装类使用「Manager」「Handler」「Service」后缀
仅包含1-2个值的配置对象

Verbosity

冗余冗长

undefined

undefined

SLOP

冗余

is_user_valid = user.is_active == true if is_user_valid == true: return true else: return false

CLEAN

优化

return user.is_active


Common patterns:

- `== true` / `== false` comparisons
- Intermediate variables used once
- `if x: return true; else: return false` → `return x`
- Unnecessary destructuring then reassembly

return user.is_active


常见模式：

- `== true` / `== false` 比较
- 仅使用一次的中间变量
- `if x: return true; else: return false` → 直接`return x`
- 不必要的解构后再重组

Naming

命名

Fix over-descriptive names:

```
userDataResponseObject
```
→
```
user
```
```
isCurrentlyProcessingData
```
→
```
processing
```
```
handleOnClickButtonEvent
```
→
```
onClick
```

修正过度描述的命名：

```
userDataResponseObject
```
→
```
user
```
```
isCurrentlyProcessingData
```
→
```
processing
```
```
handleOnClickButtonEvent
```
→
```
onClick
```

Structure

结构

Remove:

Empty constructors
Getters/setters that just proxy fields
Interfaces implemented by one class
Abstract classes with one child
Enums with one value

移除以下内容：

空构造函数
仅代理字段的getter/setter
仅被一个类实现的接口
仅包含一个子类的抽象类
仅含一个值的枚举

Logs/Debug

日志/调试

Remove:

Debug print/log statements
Verbose entry/exit logging:
```
Entering function X with params...
```
Success logs that spam output:
```
Successfully processed item 1 of 10000
```

Keep: error logging with context, audit logs for important operations.

移除以下内容：

调试打印/日志语句
冗长的进入/退出日志：
```
Entering function X with params...
```
产生大量输出的成功日志：
```
Successfully processed item 1 of 10000
```

保留：带上下文的错误日志、重要操作的审计日志。

Review Checklist

审查检查清单

For each changed file, ask:

Does this comment explain WHY, not WHAT?
Is this null check protecting against something that can actually happen?
Does this abstraction earn its complexity?
Could this be expressed more directly?
Is this name proportional to the scope?
Does this match existing patterns in the codebase?
Would a maintainer find this clearer or more confusing?

针对每个变更文件，思考：

该注释是否解释了原因而非内容？
该空值检查是否针对实际可能发生的情况？
该抽象层是否值得其带来的复杂度？
这段代码能否更直接地表达逻辑？
命名是否与作用范围匹配？
这段代码是否与代码库中的现有模式一致？
维护人员会觉得这段代码更清晰还是更困惑？

Guiding Principles

指导原则

Preserve behavior: Never change what the code does, only how it's expressed
Match the codebase: New code should look like it belongs—follow existing conventions
Simplify, don't clever: Prefer obvious solutions over clever ones
Earn complexity: Every abstraction, check, or layer must justify its existence
Readable > short: Clarity beats brevity when they conflict

保留功能：绝不改变代码的功能，仅优化代码的表达方式
匹配代码库：新代码应融入现有代码风格——遵循已有的规范
简化而非炫技：优先选择直观的解决方案而非巧妙的技巧
复杂度需合理：每个抽象层、检查或层级都必须证明其存在的必要性
可读性优先于简短：当可读性与简洁性冲突时，优先保证可读性

Edge Cases

边缘情况

Don't remove:

Defensive checks at API boundaries (external input)
Comments required by linters or documentation generators
Abstractions that enable testing or future extension (if justified)
Explicit type annotations in ambiguous contexts

请勿移除：

API边界的防御性检查（针对外部输入）
代码检查工具或文档生成器要求的注释
为测试或未来扩展提供支持的抽象层（若有合理依据）
模糊场景下的显式类型注解