有意义的变量名是代码的第一道注释，布尔变量用isXxx/hasXxx/canXxx开头，集合体现类型和用途，统一camelCase，长表达式拆为语义化中间变量，null检查封装成方法，Optional仅用于返回值场景，方法职责单一且不超过40行，参数超4个时封装为DTO或Builder。
用有意义的变量名代替缩写和单字母
变量名是代码的第一道注释，userId 比 uid 清晰，isEmailValid 比 flag 可读。Java 中常见错误是沿用 IDE 自动生成的 list、map、temp 这类泛化命名，尤其在嵌套逻辑里极易混淆。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 布尔变量强制用
isXxx、hasXxx、canXxx开头（如isRetryEnabled），避免status或result这类模糊词 - 集合变量体现类型和用途，如
activeUserIds优于ids；userRoleMap优于map - 避免下划线（
user_id）或驼峰混用，统一用camelCase，符合 Java Bean 规范
把长表达式拆成带语义的中间变量
像 if (user.getProfile().getPreferences().getNotificationSettings().getEmailEnabled() && !user.isBlocked()) 这种链式调用，不仅易空指针，还掩盖了业务意图。IDE 提示“Extract Variable”不是为了省事，而是为暴露逻辑节点。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 提取后变量名必须承载判断含义，例如：
boolean shouldSendEmail = isEmailEnabled(user) && !user.isBlocked(); - 把 null 检查封装进方法（如
isEmailEnabled(User user)），而非在 if 条件里反复写user != null && user.getProfile() != null... - 对重复计算的值（如
order.getItems().size()）提取为int itemCount，既提升可读性，也避免多次遍历
用 Optional 替代 null 返回值，但别滥用
Optional 的本意是明确“这个值可能不存在”，不是用来消除所有 if (x != null)。滥用会导致嵌套 Optional.ofNullable(...).map(...).orElse(...)，反而更难读。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 仅在**返回值场景**使用
Optional：比如public Optional<user> findUserById(Long id)</user>，而非private void process(Optional<user> user)</user> - 禁止将
Optional作为字段、参数或集合元素——它不是数据容器，JVM 不会对其做特殊优化 - 当需要默认行为时，优先用
orElseGet(() -> getDefaultUser())而非orElse(getDefaultUser())，避免无谓构造
方法职责单一，长度控制在一页内
超过 40 行的方法很难一眼看懂主干逻辑。很多人误以为“提取私有方法”只是为了复用，其实更重要的是**隔离关注点**：验证、转换、组装、日志应各自成块。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 一个方法只做一件事：比如
createOrderFromRequest()应调用validateOrderRequest()、buildOrderEntity()、saveAndNotify()，而不是把所有逻辑堆在一起 - 参数超过 4 个时，考虑封装为 DTO 或 builder 类，如
new OrderCreationRequestBuilder().userId(1L).items(items).build() - 避免在方法末尾加“// TODO: handle error case”这类注释——要么补上处理逻辑，要么抛出明确异常（如
throw new InvalidOrderException("missing payment method")）
可读性不是靠注释堆出来的，是靠结构本身传递意图。最常被忽略的一点：团队对“合理长度”“何时提取方法”的认知不一致，比语法问题更伤协作效率。
