JS团队：代码风格如何拯救神经和截止日期

为什么代码风格不是关于“如何写得漂亮”，而是关于“如何不疯掉”？

想象一下：你打开同事的代码，里面混杂着 var 和 let，缩进乱七八糟（有时2个空格，有时4个，有时制表符），分号时有时无。熟悉吗？如果是——你就知道这样的代码多快会把工作变成地狱。独自一人时你还能应付，但当项目中有5-10个 JavaScript 开发者时，缺乏统一的 代码风格 会扼杀生产力。

代码风格和约定不是 linter 的“任性要求”。它们是你的团队沟通的语言。当每个人都按自己的方式写代码时，代码就变成了“巴别塔”。而当你们就规则达成一致时，你们就不再花数小时在 代码审查 中争论空格，而是开始讨论架构。

在这篇文章中，我将展示如何在团队中为 JavaScript 实施代码标准，提供真实示例，并告诉你哪些工具真正能拯救截止日期。开始吧！

为什么 JavaScript 约定是基础？

JavaScript 是一种极其灵活的语言。你可以用十种不同的方式编写同一个函数。当你独自工作时，这很棒。但在团队中，灵活性会变成混乱。以下是三个原因，说明为什么 js 约定 是必备的：

\n
• 项目上手速度。 新开发者打开代码，立即理解逻辑，因为一切都“符合我们的惯例”。无需猜测 _this 是什么意思，或者为什么变量被命名为 x1。
\n
• 更少的 bug。 统一的 JavaScript 代码风格降低了愚蠢错误的可能性：这里忘了分号，那里多了逗号——linter 会捕获它们。
\n
• 代码审查不再是战场。 不再说“这里需要制表符！”，而是讨论“我们把这段逻辑提取到单独的 hook 里怎么样？”。
\n

顺便说一句，谷歌的研究表明：拥有统一代码风格的团队在审查上花费的时间减少 30%。这个数字令人印象深刻，对吧？

拯救你团队的 5 大 JavaScript 约定

我不会用一百条规则来烦你。我挑出五个基础规则，它们覆盖了 90% 的问题。其余的，根据你的需求调整。

1. 命名：说得清楚明白

糟糕的变量名是万恶之源。在 JavaScript 中，命名约定几乎已经确立：

\n
• 变量和函数使用 camelCase：userName、getUserData。
\n
• 类和 React 组件使用 PascalCase：UserProfile、ApiService。
\n
• 运行前已知的常量使用 UPPER_SNAKE_CASE：MAX_RETRY_COUNT。
\n

好与坏的例子：

// 坏：完全不清楚\nlet d = new Date();\nlet fn = () => { ... };\n\n// 好：像书一样可读\nlet currentDate = new Date();\nlet fetchUserData = () => { ... };

2. 分号：加还是不加？

这个争论比 JavaScript 本身还古老。但在团队中，最好选择一个规则并配置 ESLint。我建议——加上。ASI（自动分号插入）有时会出错，代码会在意想不到的地方崩溃。

// 没有分号——潜在错误\nlet a = 1\n[1, 2, 3].forEach(console.log) // 错误！解释器认为这是行的延续\n\n// 有分号——一切正常\nlet a = 1;\n[1, 2, 3].forEach(console.log);

3. 箭头函数 vs function

这里 JavaScript 约定建议：对回调和短函数使用箭头函数，对顶层声明使用 function（由于提升）。

// 好：回调使用箭头\nconst numbers = [1, 2, 3];\nconst doubled = numbers.map(n => n * 2);\n\n// 好：声明使用 function\nfunction calculateTotal(price, tax) {\n    return price + pr