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 是什么?
.png)
在深入分析之前,先简单介绍一下 code-simplifier。
这是 Claude Code 官方发布的一个代码简化 Agent,核心特点:
- 自动运行:写完代码后自动运行,无需手动调用
- 功能不变:核心承诺是”Never change what the code does - only how it does it”(永不改变代码做什么,只改变怎么做)
- 项目标准:会读取项目的 CLAUDE.md 来了解编码标准
- 平衡艺术:在简化和清晰之间找到平衡
用官方的话说:“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行(但读懂需要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); }
|
为什么这样更好?
- 变量命名:
vipMultiplier、couponPenalty 比匿名计算更清晰
- 易于验证:每个中间值都可以检查
- 易于扩展:新增积分规则只需添加新的变量
- 自解释:代码本身就是文档
对比:
- 原版:1行,但需要注释才能理解
- 优化版:4行,不需要注释就能理解
原则总结:不要为了炫技而写紧凑代码。显式表达意图,比展示编程技巧更重要。
原则4:标准一致性 > 个人偏好
核心理念:遵循项目特定的编码标准,而不是个人偏好。
code-simplifier 会读取项目的 CLAUDE.md 来了解编码标准,然后严格遵守。
案例:Pig 商城的服务层函数声明
在 Pig 商城项目中,我们的编码标准是:
- 优先使用
public 修饰符的普通方法
- 顶级函数使用显式返回类型注解
- 避免过度使用 Lambda 表达式
我在写数据处理服务时,最初用了这样的代码:
1 2 3 4 5 6
|
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 会拒绝这种”简化”,因为:
- 合并了不同的关注点(验证、构建、折扣、保存、通知)
- 移除了有用的抽象(每个私有方法都有明确的职责)
- 降低了可测试性(无法单独测试各个步骤)
- 降低了可维护性(修改折扣逻辑需要改动主方法)
原则总结:简化不是目的,清晰和可维护才是。不要为了减少行数而牺牲代码组织。
如何使用 code-simplifier?
看到这里,你可能想试试 code-simplifier。安装和使用非常简单。
1. 安装 code-simplifier 插件
打开 Claude Code,依次执行以下命令:
1 2 3 4 5
| /plugin marketplace update claude-plugins-official
/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; }
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。
这不只是代码质量的提升,还是成本优化。