17370845950

有意义的变量名是代码的第一道注释，布尔变量用isXxx/hasXxx/canXxx开头，集合体现类型和用途，统一camelCase，长表达式拆为语义化中间变量，null检查封装成方法，Optional仅用于返回值场景，方法职责单一且不超过40行，参数超4个时封装为DTO或Builder。

用有意义的变量名代替缩写和单字母

变量名是代码的第一道注释，userId 比 uid 清晰，isEmailValid 比 flag 可读。Java 中常见错误是沿用 IDE 自动生成的 list、map、temp 这类泛化命名，尤其在嵌套逻辑里极易混淆。

实操建议：

• 布尔变量强制用 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”不是为了省事，而是为暴露逻辑节点。

实操建议：

• 提取后变量名必须承载判断含义，例如：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)。滥用会导致嵌套 Opt

实操建议：

• 仅在**返回值场景**使用 Optional：比如 public Optional findUserById(Long id)，而非 private void process(Optional user)
• 禁止将 Optional 作为字段、参数或集合元素——它不是数据容器，JVM 不会对其做特殊优化
• 当需要默认行为时，优先用 orElseGet(() -> getDefaultUser()) 而非 orElse(getDefaultUser())，避免无谓构造

方法职责单一，长度控制在一页内

超过 40 行的方法很难一眼看懂主干逻辑。很多人误以为“提取私有方法”只是为了复用，其实更重要的是**隔离关注点**：验证、转换、组装、日志应各自成块。

实操建议：

• 一个方法只做一件事：比如 createOrderFromRequest() 应调用 validateOrderRequest()、buildOrderEntity()、saveAndNotify()，而不是把所有逻辑堆在一起
• 参数超过 4 个时，考虑封装为 DTO 或 builder 类，如 new OrderCreationRequestBuilder().userId(1L).items(items).build()
• 避免在方法末尾加“// TODO: handle error case”这类注释——要么补上处理逻辑，要么抛出明确异常（如 throw new InvalidOrderException("missing payment method")）

可读性不是靠注释堆出来的，是靠结构本身传递意图。最常被忽略的一点：团队对“合理长度”“何时提取方法”的认知不一致，比语法问题更伤协作效率。