📌 项目地址：ryanmcdermott/clean-code-javascript | ⭐ 94,523 颗星 | 🔧 JavaScript | 📜 未标注
为什么需要这样一份指南？
很多开发者写JavaScript时，逻辑跑通了就急着提交，代码里到处是 data、tmp、handleClick 这样的命名，函数长达上百行，混合着异步和副作用。三个月后回头一看，自己都看不懂。
这不是你的错。JavaScript语法灵活，没有强制的代码规范，团队协作中代码风格和设计原则的混乱几乎是必然的。Robert C. Martin 的《Clean Code》提出了软件工程的基本原则，但原文示例基于Java，直接迁移到JavaScript有隔阂。
clean-code-javascript 就是为此而生——它把《Clean Code》的核心思想用JavaScript的语境重新表达，没有添加任何魔法，只是通过正反示例告诉你：怎样的代码更易读、更易维护、更易重构。
它讲了什么？——从变量到并发，覆盖全链路
项目按主题分为11个章节。每个章节都是“Bad → Good”对比，没有废话。我们来看几个典型例子：
变量命名：有意义且可搜索
Bad:
const yyyymmdstr = moment().format("YYYY/MM/DD");
Good:
const currentDate = moment().format("YYYY/MM/DD");
yyyymmdstr 需要读者猜测含义，而 currentDate 一目了然。这里的关键不是格式，而是变量名应该揭示意图。
函数：避免过多参数
Bad:
function createMenu(title, body, buttonText, cancellable) { ... }
Good:
function createMenu({ title, body, buttonText, cancellable }) { ... }
使用解构对象作为参数，调用时传参顺序不再重要，新增字段也不会影响已有调用。
类：组合优于继承
Bad:
class Employee {
constructor(name, email) { ... }
// 如果将来需要经理、销售、工程师，类继承会急速膨胀
}
Good:
class Employee {
constructor(name, email) { ... }
}
// 将职责委托给策略对象
class EmployeeType { ... }
这一点与SOLID原则中的开闭原则呼应。
并发：避免共享状态
Bad:
let counter = 0;
[1,2,3].forEach(i => { counter += i; });
Good:
const total = [1,2,3].reduce((acc, i) => acc + i, 0);
使用纯函数和不可变数据，减少副作用。
这和ESLint、Prettier有什么区别？
很多人会把它和代码风格工具混淆。风格工具只管格式（缩进、分号、引号），而 clean-code-javascript 关注的是设计层面的可读性和可维护性。比如：
- 变量名是否表达意图
- 函数是否只做一件事
- 是否有重复代码
- 错误处理是否统一
这些无法通过自动化工具完全检查，需要开发者形成意识。项目中提到的 buddy.js 和 ESLint 的 no-magic-numbers 规则可以辅助，但核心是人的判断。
我该怎么用它？需要注意什么？
使用方法：直接阅读项目根目录的 README.md，不需要安装任何依赖，也没有CLI命令。你可以把它当作团队代码评审的参考清单，或者个人编写的自查表。
需要注意：
1. 这是指南，不是规则。项目前言明确强调：“Not every principle herein has to be strictly followed, and even fewer will be universally agreed upon.” 盲目套用会导致僵化。例如在原型或一次性脚本中，过度抽象反而浪费时间。
2. 部分示例偏向传统OOP（面向对象编程），而现代JavaScript越来越多使用函数式组合。你可以吸收其核心理念（如单一职责、依赖反转），不必照搬类的写法。
3. 项目已有94.5k star，被翻译成20多种语言（见README的Translation章节），认可度极高，但请记住——它不覆盖性能优化、安全等主题。
适合谁读？
如果你写JavaScript时经常陷入：
– “这个变量该叫什么？”
– “这个函数要不要拆？”
– “这段重复代码怎么处理？”
– “团队成员风格不一致，评审时总吵架”
那这份指南就是为你准备的。它更像一本需要持续翻看的“原则手册”，而不是一本看一次就丢弃的教程。