1.1风格圣战与协作困境

1.1 风格圣战与协作困境

争论从何而来

开发者对代码风格有偏好，这件事本身不奇怪。就像作家有文风，建筑师有设计倾向，写代码的人也会在长期的实践中形成自己的编码习惯。有人喜欢用分号标记语句结尾，觉得这样边界清晰；有人觉得分号多余，JavaScript 的 ASI 机制已经做了这件事。有人习惯 Tab 缩进，因为一个字符就能表达一个层级；有人坚持两个空格，因为不同编辑器对 Tab 的渲染宽度不一样。

这些偏好本身没有对错之分。console.log('hello'); 和 console.log("hello") 在运行时产生完全相同的效果。但问题在于，当多个不同偏好的人共同维护同一个代码库时，差异就成了摩擦源。

这种摩擦在代码审查场景中尤为明显。一个典型的场景是：开发者提交了一段功能代码，逻辑正确，测试通过，但在审查评论区，最先出现的几条回复是"这里应该用单引号"、"缩进应该是两个空格"、"最后一个属性后面加尾随逗号"。开发者不得不切回去改这些格式问题，重新提交，再等一轮 CI 跑完。

这个循环反复发生，每次消耗 10-30 分钟。一天下来，一个五人团队可能因为格式问题浪费掉 1-2 小时。一个月就是 20-40 小时——相当于一个人一周的工作量全部浪费在了跟业务逻辑毫无关系的格式修正上。

认知负荷的隐性成本

格式不统一带来的不只是时间浪费，还有一种更隐蔽的成本：认知负荷。

人的工作记忆容量有限。当你阅读一段代码时，大脑在做的事情远不止"理解这段代码做了什么"——它同时在处理视觉层面的信号：缩进层级、括号位置、空行间隔、对齐方式。如果整个文件的风格一致，大脑会在快速浏览中自动建立起一套视觉预期，然后专注于语义理解。

但当风格在同一个文件中来回切换——前一节用 Tab 缩进，后一节变成两个空格；函数调用有时写在同一行，有时每个参数独占一行——大脑就不得不在理解语义的同时处理这些视觉噪声。这种额外的处理不是有意识的，但它确实在消耗你的认知带宽，让你更容易疲劳、更容易漏掉真正的逻辑问题。

这就像在一条路上开车，如果道路标线始终清晰一致，你可以把注意力放在路况上；但如果标线忽左忽右、时有时无，你就会不自觉地把部分注意力分配到"判断自己是否还在正确车道上"，留给观察前方路况的余力就少了。

新人融入的额外壁垒

新加入团队的成员面对风格不统一的代码库，负担更重。他们需要同时学习三件事：业务逻辑、技术栈、以及"这个项目的代码长什么样"。

第三件事在很多项目中没有文档化。风格规则可能散落在 ESLint 配置、团队 Wiki 的某个角落、以及资深成员的肌肉记忆里。新人只能通过模仿现有代码来"感受"风格，而这个过程充满了不确定性——如果他们模仿的是一份风格不同的文件呢？

就算有明确的风格指南，执行也需要时间。新人在写代码时要额外分心"这里该用单引号还是双引号"、"这个换行对不对"，这些微决策增加了编码时的摩擦感。如果他们在不确定的时候选了"错"的格式，收到格式相关的 review 评论，还会产生挫败感。

git diff 的信息污染

格式不统一还有一个技术上的具体代价：污染 git diff。

假设你修复了一个变量名拼写错误，只改了一个字符。但因为你在编辑时"顺手"把缩进从 Tab 改成了两个空格、把单引号改成了双引号、调整了几处换行，最终的 diff 可能显示几十行改动。审查者必须逐行确认哪些是真正的逻辑变更，哪些只是格式调整。

如果项目同时存在多种风格的历史代码，这种问题更加严重。你在修改一段"旧风格"的代码时，无论是否调整格式都会尴尬：不调格式的话改动区域和新代码风格不搭；调格式的话 diff 里就多出一堆噪音。

前格式化器时代的解决方案

在 Prettier 出现之前，业界并非没有尝试解决这些问题。主要的方案有几类：

ESLint 风格规则。ESLint 本质上是代码质量检查工具，但它内置了大量风格相关规则（indent、quotes、semi 等）。团队可以用 ESLint 强制执行风格规范。但问题是 ESLint 的风格规则加起来有上百条，团队需要逐条决定开启哪些、怎么配置参数。配置本身就成了一场新的争论——"我们要不要开 comma-dangle？参数写几个才换行？"而且 ESLint 只能报告问题，不能像格式化器那样直接重写代码，修复还是要靠手动或编辑器的 auto-fix，后者经常改不到理想状态。

共享配置包。社区出现了 eslint-config-airbnb、eslint-config-standard 这样的共享配置，团队声明"我们用 Airbnb 规范"就能省去逐条配置的麻烦。但这只是把争论从"每条规则选什么"转移到了"选哪套共享配置"——如果团队成员不认同某条规则，争论又会重启。

书面的风格指南。很多大公司有内部编码规范文档。但文档无法自动执行，依赖人的自觉遵守。人的记忆力有限、注意力不持久，纯靠文档约束的规范在工程实践中几乎不可能长期保持一致。

图 1-1：传统方案的共同困境

这三类方案的共同缺陷是：它们要么需要大量决策（配置 ESLint），要么无法解决根本分歧（共享配置的选择权问题），要么缺乏执行力（文档规范）。真正的问题——"谁来拍板风格"——一直没有被回答。

Prettier 给出的回答是：我不让你选。这个回答之所以有效，下一节会详细解释。

量化争论的代价

让我们用一个简单的框架来量化风格争论的成本。假设一个 10 人团队，每个 PR 平均被审查 2 轮，每轮因格式问题被退回的概率是 40%，每次退回和重新提交平均消耗 20 分钟：

• 每天 5 个 PR × 40% 退回率 × 20 分钟 = 40 分钟/天
• 每月约 20 个工作日 = 800 分钟 ≈ 13 小时/月
• 每年 = 约 160 小时，相当于一个人一个月的工作量

这还只是直接的时间成本。如果加上认知负荷、新人上手延迟、团队氛围受损这些隐性成本，实际数字会更高。

这些数字不需要精确到个位就能说明问题：风格争论是一个持续消耗团队资源的"慢性病"，它不致命，但一直在拖慢组织的整体效率。