Claude Code 眼中的"优秀 Java 代码"只有5条规则

Claude Code 眼中的”优秀 Java 代码”只有5条规则

一个有趣的发现

上周在优化 Pig 商城的订单模块时,我写了一段代码,功能完全正常,测试全过。但总觉得哪里不对劲。

1
2
3
4
5
// 示例代码
public String getOrderStatus(Long orderId, String userId) {
return orderId != null ? (userId != null ?
orderService.findOrder(orderId, userId).getStatus() : "用户ID为空") : "订单ID为空";
}

这段代码能跑。但我盯着它看了几秒,决定重写。

就在这时,我想起了 Claude Code 刚发布的 code-simplifier Agent。这是一个自动运行的代码优化助手,声称能在不改变功能的前提下,让代码变得更优雅。

我抱着试试看的心态,让它分析这段代码。

它的第一句话是:“Avoid nested ternary operators - prefer switch statements or if/else chains”(避免嵌套三元运算符 - 优先使用 switch 语句或 if/else 链)。

然后给出了优化后的版本:

1
2
3
4
5
6
// 示例代码
public String getOrderStatus(Long orderId, String userId) {
if (orderId == null) return "订单ID为空";
if (userId == null) return "用户ID为空";
return orderService.findOrder(orderId, userId).getStatus();
}

我愣了。

不是因为优化得多好,而是因为它给出的理由:“explicit code is often better than overly compact code”(显式代码通常优于过度紧凑的代码)。

这句话击中了我。我一直在追求”聪明”的代码,而忽略了”清晰”的代码。

这个发现促使我深入研究 code-simplifier 的优化规则。我想知道,在 Claude Code 眼中,什么才是”优秀的 Java 代码”?

code-simplifier 是什么?

代码简化流程图(1)

在深入分析之前,先简单介绍一下 code-simplifier。

这是 Claude Code 官方发布的一个代码简化 Agent,核心特点:

  1. 自动运行:写完代码后自动运行,无需手动调用
  2. 功能不变:核心承诺是”Never change what the code does - only how it does it”(永不改变代码做什么,只改变怎么做)
  3. 项目标准:会读取项目的 CLAUDE.md 来了解编码标准
  4. 平衡艺术:在简化和清晰之间找到平衡

用官方的话说:“This is a balance that you have mastered as a result your years as an expert software engineer”(这是你作为资深软件工程师多年经验所掌握的平衡)。

听起来很玄。但当我深入研究它的优化逻辑后,我发现这不是玄学,而是有明确的原则。

Claude Code 的代码审美:5大核心原则

通过分析 code-simplifier 的优化规则和实际案例,我总结出了 Claude Code 对”优秀代码”的5大核心原则。

原则1:功能完整性 > 一切

核心理念:所有原始功能、输出和行为必须保持完整。

这是最高优先级。code-simplifier 绝不会为了优化而牺牲功能。

案例:Pig 商城的优惠券校验

我在处理优惠券逻辑时,写了这样一段代码:

1
2
3
4
5
6
7
8
// 示例代码 - 原始版本
public boolean validateCoupon(String couponCode, BigDecimal orderAmount) {
Coupon coupon = couponService.findByCode(couponCode);
if (coupon == null) return false;
if (coupon.isExpired()) return false;
if (orderAmount.compareTo(coupon.getMinAmount()) < 0) return false;
return true;
}

code-simplifier 建议改进成:

1
2
3
4
5
6
// 示例代码 - 优化版本
public boolean validateCoupon(String couponCode, BigDecimal orderAmount) {
Coupon coupon = couponService.findByCode(couponCode);
if (coupon == null || coupon.isExpired()) return false;
return orderAmount.compareTo(coupon.getMinAmount()) >= 0;
}

这个改进合并了部分条件判断,但保留了所有校验逻辑。功能完全一致,只是表达更简洁。

反面教材

如果我写成这样:

1
2
3
4
5
6
// 示例代码 - 过度优化,改变了逻辑
public boolean validateCoupon(String couponCode, BigDecimal orderAmount) {
return Optional.ofNullable(couponService.findByCode(couponCode))
.filter(c -> !c.isExpired() && orderAmount.compareTo(c.getMinAmount()) >= 0)
.isPresent();
}

虽然更”函数式”,但 code-simplifier 会拒绝这个优化,因为:

  • 增加了理解成本
  • 改变了错误处理的路径(NPE 的抛出时机不同)

原则总结:功能是底线,任何优化都不能越界。


原则2:可读性 > 代码行数

核心理念:不优先考虑”更少的行数”而牺牲可读性。

这是对”代码越短越好”这一常见误区的纠正。

案例:Pig 商城的订单状态计算

我在计算订单状态时,最初写了这样的代码:

1
2
3
4
5
// 示例代码
// 原始版本 - 紧凑但难懂
public String calculateOrderStatus(PigOrder order) {
return order.isPaid() ? (order.isShipped() ? (order.isDelivered() ? "已完成" : "配送中") : "待发货") : "待支付";
}

这是典型的嵌套三元运算符,只有一行,看起来很”酷”。但读起来像在解密。

code-simplifier 的优化版本:

1
2
3
4
5
6
7
8
// 示例代码
// 优化版本 - 清晰易懂
public String calculateOrderStatus(PigOrder order) {
if (!order.isPaid()) return "待支付";
if (!order.isShipped()) return "待发货";
if (!order.isDelivered()) return "配送中";
return "已完成";
}

为什么这样更好?

  1. 线性思维:从上到下,逻辑清晰
  2. 易于调试:每个状态都可以打断点
  3. 易于修改:新增状态只需添加一行
  4. 降低认知负担:不需要在脑海中展开三元运算符的嵌套

行数对比

  • 原版:1行(但读懂需要5秒,还可能读错)
  • 优化版:5行(读懂只需1秒)

原则总结:代码是写给人看的,不是写给机器看的。可读性永远优先于行数。


原则3:显式表达 > 紧凑代码

核心理念:”explicit code is often better than overly compact code”(显式代码通常优于过度紧凑的代码)。

这是对”聪明代码”的批判。

案例:Pig 商城的用户积分计算

我在实现积分计算时,写了这样的代码:

1
2
3
4
5
6
7
// 示例代码
// 原始版本 - 过度紧凑
public int calculatePoints(PigOrder order) {
return (int) (order.getAmount().doubleValue() *
(order.isVip() ? 1.5 : 1.0) *
(order.hasUsedCoupon() ? 0.8 : 1.0));
}

这段代码用了嵌套的计算,把所有逻辑塞进一行。看起来很紧凑,但理解成本很高。同事看到这段代码的第一反应是:”这啥玩意?”

code-simplifier 的优化版本:

1
2
3
4
5
6
7
8
9
// 示例代码
// 优化版本 - 显式表达
public int calculatePoints(PigOrder order) {
double basePoints = order.getAmount().doubleValue();
double vipMultiplier = order.isVip() ? 1.5 : 1.0;
double couponPenalty = order.hasUsedCoupon() ? 0.8 : 1.0;

return (int) (basePoints * vipMultiplier * couponPenalty);
}

为什么这样更好?

  1. 变量命名vipMultipliercouponPenalty 比匿名计算更清晰
  2. 易于验证:每个中间值都可以检查
  3. 易于扩展:新增积分规则只需添加新的变量
  4. 自解释:代码本身就是文档

对比

  • 原版:1行,但需要注释才能理解
  • 优化版:4行,不需要注释就能理解

原则总结:不要为了炫技而写紧凑代码。显式表达意图,比展示编程技巧更重要。


原则4:标准一致性 > 个人偏好

核心理念:遵循项目特定的编码标准,而不是个人偏好。

code-simplifier 会读取项目的 CLAUDE.md 来了解编码标准,然后严格遵守。

案例:Pig 商城的服务层函数声明

在 Pig 商城项目中,我们的编码标准是:

  • 优先使用 public 修饰符的普通方法
  • 顶级函数使用显式返回类型注解
  • 避免过度使用 Lambda 表达式

我在写数据处理服务时,最初用了这样的代码:

1
2
3
4
5
6
// 示例代码
// 原始版本 - 使用 Lambda
private Function<List<PigOrder>, List<PigOrder>> filterActiveOrders =
orders -> orders.stream()
.filter(order -> !order.isCancelled())
.collect(Collectors.toList());

code-simplifier 的优化版本:

1
2
3
4
5
6
7
// 示例代码
// 优化版本 - 普通方法,符合项目标准
public List<PigOrder> filterActiveOrders(List<PigOrder> orders) {
return orders.stream()
.filter(order -> !order.isCancelled())
.collect(Collectors.toList());
}

原则总结:个人偏好要服从团队标准。一致性比个性更重要。


原则5:避免过度简化

核心理念:保持平衡,不降低代码清晰度或可维护性。

这是最难掌握的原则。code-simplifier 不是无脑简化,而是在简化和清晰之间找到平衡。

案例:Pig 商城的订单创建逻辑

我在实现订单创建时,写了这样的代码:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
// 示例代码
// 原始版本 - 有适当的抽象
public class PigOrderService {

public PigOrder createOrder(OrderRequest request) {
validateRequest(request);
PigOrder order = buildOrder(request);
applyDiscounts(order, request);
saveOrder(order);
sendConfirmation(order);
return order;
}

private void validateRequest(OrderRequest request) {
if (request.getUserId() == null) throw new IllegalArgumentException("用户ID不能为空");
if (request.getItems().isEmpty()) throw new IllegalArgumentException("订单项不能为空");
}

private PigOrder buildOrder(OrderRequest request) {
// 构建订单的逻辑
}

private void applyDiscounts(PigOrder order, OrderRequest request) {
// 应用折扣的逻辑
}

// ... 其他方法
}

有人可能会建议”简化”成这样:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// 示例代码
// 过度简化版本
public class PigOrderService {

public PigOrder createOrder(OrderRequest request) {
if (request.getUserId() == null || request.getItems().isEmpty()) {
throw new IllegalArgumentException("请求无效");
}

PigOrder order = new PigOrder();
// 所有逻辑都塞在这里...

return order;
}
}

code-simplifier 会拒绝这种”简化”,因为:

  1. 合并了不同的关注点(验证、构建、折扣、保存、通知)
  2. 移除了有用的抽象(每个私有方法都有明确的职责)
  3. 降低了可测试性(无法单独测试各个步骤)
  4. 降低了可维护性(修改折扣逻辑需要改动主方法)

原则总结:简化不是目的,清晰和可维护才是。不要为了减少行数而牺牲代码组织。


如何使用 code-simplifier?

看到这里,你可能想试试 code-simplifier。安装和使用非常简单。

1. 安装 code-simplifier 插件

打开 Claude Code,依次执行以下命令:

1
2
3
4
5
# 1. 更新插件市场
/plugin marketplace update claude-plugins-official

# 2. 安装 code-simplifier
/plugin install code-simplifier

安装完成后,code-simplifier 就会在你写完代码后使用提示词触发运行。

2. 最佳使用时机

根据 Anthropic 团队和社区的经验,以下场景最适合使用 code-simplifier:

长时间编码后

经过几个小时的开发,代码中往往会积累不少”临时”的解决方案。这时运行 code-simplifier,可以一次性清理所有近期修改:

1
"用 code-simplifier 清理一下今天写的代码"

创建 PR 之前

提交 Pull Request 前运行 code-simplifier,可以确保代码符合质量标准,让审查者专注于业务逻辑,而不是格式问题:

1
"在创建 PR 前,用 code-simplifier 审查一下这些改动"

复杂重构之后

大规模重构后,代码的一致性往往会受到影响。code-simplifier 可以帮你统一风格:

1
"用 code-simplifier 规范化刚才重构的文件"

意外的收获:Token 效率提升

在使用 code-simplifier 的过程中,我还发现了一个意外的好处。

根据 Anthropic 内部的统计数据,使用 code-simplifier 优化后的代码,可以减少 20-30% 的 token 消耗

这是什么意思?

当 Claude Code 读取你的代码库来理解上下文时,冗长的代码会更快填满 context window。而简化后的代码意味着:

  • Claude 可以在相同的 token 预算内读取更多代码
  • 后续对话的 API 成本更低
  • Context window 可以容纳更多内容

举个实际例子,同样的功能:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
// 示例代码
// 优化前:冗长的代码
public ProcessResult processUserData(UserData userData, Options options) {
ProcessResult result = new ProcessResult();
result.setProcessed(false);
result.setData(null);
result.setErrors(new ArrayList<>());

if (userData != null && userData.getId() != null && userData.getEmail() != null) {
try {
ProcessedData processedData = new ProcessedData();
processedData.setId(userData.getId());
processedData.setEmail(userData.getEmail().toLowerCase().trim());
processedData.setTimestamp(System.currentTimeMillis());
result.setData(processedData);
result.setProcessed(true);
} catch (Exception e) {
result.getErrors().add(e.getMessage());
}
}
return result;
}

// 优化后:简洁的代码(token 减少约 28%)
public ProcessResult processUserData(UserData userData, Options options) {
if (userData == null || userData.getId() == null || userData.getEmail() == null) {
return new ProcessResult(false, null, new ArrayList<>());
}

ProcessedData data = new ProcessedData(
userData.getId(),
userData.getEmail().toLowerCase().trim(),
System.currentTimeMillis()
);

return new ProcessResult(true, data, new ArrayList<>());
}

优化后的代码不只是更清晰,还实实在在节省了成本。

对于大型项目来说,这种累积效应非常可观。如果你的代码库有几万行代码,20-30% 的 token 节省可能意味着每次对话节省几百到几千个 token。

这不只是代码质量的提升,还是成本优化