编写简洁代码的 10 条万无一失的规则 🔥

如果你身处一个凌乱的房间，就找不到钥匙了。衣服到处都是，书也堆得老高。

GIF

这同样适用于混乱的代码。情况是一样的，只不过现在消耗能量的是你的大脑。

另一方面，整洁的代码就像走进一个一尘不染的房间。一切都井然有序，没有压力，没有困惑，只有清晰明了。

事实是：如果你想在软件开发领域生存下去，编写简洁的代码绝非可有可无。人工智能编写的代码都比你简洁。

幸运的是，作为地球上最伟大的造物，我们人类能够掌握编写简洁代码的能力。

你可以编写混乱的代码，然后疲于奔命地修复每一个bug，最终求职面试被拒，也无法建立一个可管理的创业公司；或者你可以掌握编写简洁代码的技巧，并在你经手的每一个项目中都占据主导地位。

代码整洁者 vs. 代码混乱者

下图展示了两种类型程序员的职业发展历程：

• ⚠️ 糟糕的程序员（红线）：开头很快，但很快就崩溃了。他们写的代码越多，造成的麻烦就越多。
• ⚡ 代码整洁度（蓝线）：起步缓慢但保持稳定。增长不会停止，反而会加速。

🫵 现在，你来决定你想走哪条路。

🐦早鸟特惠：五折优惠🚨

如果你真心想要掌握简洁代码的编写方法，并将你的编程生涯提升到一个新的高度，那么这本书就是为你量身打造的： 《从零到一：代码整洁之道》 。我提供五折优惠，使用优惠码“earlybird”即可享受——仅限前50名！此外，还享有30天退款保证——零风险，全额回报。或者，你也可以继续苦苦挣扎于你那漏洞百出的代码中。我可没法亲自到你的办公桌前帮你修复。

糟糕代码的代价

为了说明这张图表，在初始开发阶段，修改糟糕的代码比修改干净的代码成本略高。

然而，随着我们进入维护和重构阶段，差距显著扩大，糟糕的代码造成的损失几乎是干净代码的两倍。

到了遗留阶段，糟糕的代码成本会达到 100%，现在更新成本极其高昂，而干净的代码仍然更容易管理，成本仅为 45%。

毫无疑问，糟糕的代码是软件开发中一个代价高昂的问题。

编写整洁代码的 10 条万无一失的规则

1. 使用有意义的名称

把变量或函数命名为b或x是犯罪行为。请用它们实际的名称来命名。

// Weak and vague
let b = 5;

// Strong and clear
let numberOfUsers = 5;

写名字含糊不清的人是不想承认错误。别做这样的人。

2. 保持功能聚焦（SRP）

一个函数应该只做一件事——而且要把它做到极致。这被称为单一职责原则（SRP）。

好的代码就像一把锤子，它只敲中一个钉子，而不是十个。

// Clean: One job, one focus
function calculateTotal(a, b) {
    return a + b;
}

function logTotal(user, total) {
    console.log(`User: ${user}, Total: ${total}`);
}

// Dirty: Trying to do EVERYTHING
function calculateAndLogTotal(a, b, user) {
    let total = a + b;
    console.log(`User: ${user}, Total: ${total}`);
}

把不同的任务混在一起，就会造成混乱和灾难。

3. 沉默的评论

你不需要每次有人走进房间都解释门的作用。你的代码也应该遵循同样的原则。

// Clean: Self-explanatory
let userAge = 25;

// Messy: Needs an explanation
let a; // This means "age of the user"

注释本身并没有错，但如果你的代码不能独立运行，你就已经失败了。

4. 让你的代码易于阅读

如果阅读你代码的人感觉像是在解谜，那么你已经成了个麻烦制造者。

// Clean: Reads like a story
if (isLoggedIn) {
    console.log("Welcome!");
} else {
    console.log("Please log in.");
}

// Messy: Feels like chaos
if(isLoggedIn){console.log("Welcome!");}else{console.log("Please log in.");}

可读性强的代码不仅是为了方便他人阅读，也是为了六个月后的你自己。

5. 测试你写的所有内容

如果你懒得写测试，代码出错时就不要抱怨。

class Calculator {
    add(a, b) { return a + b; }
    subtract(a, b) { return a - b; }
}

// Test it (Unit Test)
const calculator = new Calculator();
console.assert(calculator.add(2, 3) === 5, "Addition failed");
console.assert(calculator.subtract(5, 3) === 2, "Subtraction failed");

考试就像你的保险。忽视考试，就是在拿时间冒险。

6. 注意依赖关系

依赖关系就像交易。选对了，你就赢了。选错了，你就被困在会后悔的境地里。

// Dependency: Sending emails with Nodemailer
const nodemailer = require('nodemailer');
function sendEmail(to, subject, message) {
    const transporter = nodemailer.createTransport({ /* config */ });
    return transporter.sendMail({ from: "you@example.com", to, subject, text: message });
}

避免将依赖项硬编码到代码中。使用抽象层或配置文件进行安全维护。

这只是一个例子。作为开发人员，你可能会用到数百个库或依赖项。

我并不是说你不应该依赖它们，现在很难完全避免使用它们。但是，在将它们安装到你的代码项目中之前，你一定要非常谨慎。

您应该检查组织软件系统的安全性、性能、质量或功能。因为它们有时包含可能毁掉您整个项目的风险。

永远要掌控你的工具，不要让工具掌控你。

7. 像老板一样组织项目

一个组织良好的项目，是车库甩卖和高端精品店之间的区别。

以下是每个文件夹的正确组织方式：

如果你的代码库看起来像个杂物抽屉，你已经失去了未来自己的尊重。

邮件应用的清晰项目结构：
假设您正在构建一个向用户发送电子邮件的应用程序。您的清晰项目结构应该如下所示：

8. 保持格式一致

不要像个有十种人格的人那样写代码。保持格式一致。

使用Prettier或ESLint等工具来强制执行一致的代码风格。如果每个文件看起来都不一样，就会造成混乱，而且没人愿意去修复。

我认为，格式的一致性是编写高质量代码最重要的方面之一。

请看……

在整个代码库中，缩进应始终使用2 个或 4 个空格。避免使用制表符，以保持不同编辑器之间的一致性。

为防止横向滚动并提高可读性，每行最多只能包含 100-120 个字符。

将相关的逻辑组合 在一起，并用空行分隔代码块，以突出其用途。

最后，避免过度对齐代码；相反，让缩进自然地引导逻辑流程。

9. 停止硬编码值

硬编码是把懒惰伪装成努力。

// Bad: Hardcoded and rigid
function createUser() {
    const maxUsers = 100;
    if (currentUsers >= maxUsers) throw "Too many users!";
}

// Clean: Dynamic and flexible
const MAX_USERS = 100;
function createUser() {
    if (currentUsers >= MAX_USERS) throw "Too many users!";
}

所以，务必避免使用硬编码。硬编码是通往悬崖的捷径。

10. 保持函数简短

如果你的函数超过 20 行，它可能试图完成太多任务。把它拆分成多个部分。

function updateCart(cart, item) {
    addItemToCart(cart, item);
    let total = calculateTotal(cart);
    logTransaction(item, total);
    return total;
}

function addItemToCart(cart, item) {
    cart.items.push(item);
}

短函数就是精准函数。它们每次都能准确命中目标。

阅读更多：如何在 React 中编写简洁、可复用的组件