第22章代码整洁之道概述

课程目录第22章代码整洁之道概述

代码整洁之道概述：整洁代码的含义、命名规范、函数设计原则

各位同学，咱们今天聊聊代码整洁之道。说实话，我入行头三年写的代码，现在回头看简直想找个地缝钻进去。那时候觉得能跑就行，管它乱不乱。直到有一次，一个紧急bug让我在两千行的函数里翻了整整一个下午——嗯，从那以后，我彻底改观了。

整洁代码不是花架子，它是你职业生涯的护身符。你想想看，代码写出来首先是给人看的，其次才是给机器执行的。机器不挑食，但你的同事会骂娘。

什么是整洁代码

整洁代码，说白了就是读起来像是一篇好文章。它有自己的节奏，有清晰的逻辑，每个函数都在讲一个完整的故事。

我个人习惯用一个标准来判断：如果一段代码让你想骂人，那它就不整洁。反过来，如果你读代码时能顺畅地点头，那就是好代码。

整洁代码的三个核心特征：

可读性强——变量名、函数名一看就懂，不需要猜
职责单一——每个函数只做一件事，且做好
易于修改——改一处不会崩三处

我在项目中遇到过最典型的反面教材：一个叫 processData 的函数，里面同时做了数据校验、格式转换、写入数据库、发送邮件。你猜怎么着？后来要改邮件模板，结果把数据库写挂了。这就是不整洁的代价。

命名规范：名字就是最好的注释

命名这件事，我踩过的坑比写过的代码还多。曾经我特别喜欢用 a、b、tmp 这种变量名，觉得省事。结果呢？三天后自己都看不懂了。

好的命名应该做到：看到名字就知道它是什么、干什么用。

坏命名	好命名	说明
`int d;`	`int daysSinceLastLogin;`	明确含义，不用猜
`list`	`List<User> activeUsers;`	带上类型和用途
`getData()`	`fetchUserProfile()`	具体到做什么
`flag`	`isPaymentCompleted`	布尔值用 is/has/can 开头

我的命名小技巧：

类名用名词：Customer、OrderProcessor
方法名用动词：calculateTotal()、saveToDatabase()
布尔变量用 is/has/can：isValid、hasPermission
避免缩写：idx 不如 index，cfg 不如 config

我曾经接手过一个项目，里面有个变量叫 xxx。你没看错，就是三个x。我查了git记录，原作者说"临时用一下，回头改"。结果这个"临时"用了两年。嗯，后来我花了三天才搞清楚它到底存的是什么。

函数设计原则：小而美

函数设计，我有一条铁律：一个函数只做一件事。如果函数名里出现了"和"字，那大概率是设计有问题。

举个例子，下面这个函数就犯了典型的"贪多"毛病：

// 坏例子：一个函数做了三件事
public void processOrder(Order order) {
    // 1. 校验订单
    if (order.getTotal() <= 0) {
        throw new IllegalArgumentException("订单金额无效");
    }
    // 2. 计算折扣
    double discount = 0;
    if (order.getTotal() > 1000) {
        discount = 0.1;
    }
    // 3. 保存订单
    database.save(order);
    emailService.sendConfirmation(order);
}

这个函数干了三件事：校验、计算、保存。哪天要改折扣规则，你得从整个函数里抠逻辑。改成这样就好多了：

// 好例子：每个函数只做一件事
public void processOrder(Order order) {
    validateOrder(order);
    double discount = calculateDiscount(order);
    saveOrderWithDiscount(order, discount);
}

private void validateOrder(Order order) {
    if (order.getTotal() <= 0) {
        throw new IllegalArgumentException("订单金额无效");
    }
}

private double calculateDiscount(Order order) {
    if (order.getTotal() > 1000) {
        return 0.1;
    }
    return 0;
}

private void saveOrderWithDiscount(Order order, double discount) {
    order.setDiscount(discount);
    database.save(order);
    emailService.sendConfirmation(order);
}

你看，每个函数都短小精悍，名字就是它的说明书。改折扣？直接去 calculateDiscount 里改，不会动到其他逻辑。

函数设计的避坑指南：

函数不要超过20行——超过就考虑拆分
参数不要超过3个——多了就封装成对象
避免副作用——函数不要偷偷改全局变量
不要用布尔参数控制流程——拆成两个函数更清晰

我曾经在一个项目里看到过300行的函数，里面嵌套了6层if-else。当时要加一个新功能，我盯着屏幕看了半小时，愣是没敢下手。最后花了整整一天重构，拆成12个小函数。测试通过的那一刻，我差点哭了。

知识体系总览

下面这张图，是我对整洁代码核心思想的总结。你可以把它当作一个检查清单：

这张图把整洁代码拆成了三个维度：可读性是基础，命名规范和函数设计是具体落地手段。你写代码的时候，可以拿这个图当镜子照一照——你的代码，经得起照吗？

最后送你三句话，我贴了十年在工位上：

写代码的时候，想象一下半年后的自己会怎么骂现在的你。
整洁代码不是一次写成的，是反复打磨出来的。
对代码负责，就是对同事负责，更是对自己负责。