2.2 格式化与风格检查：给台面装定规

2.2 格式化与风格检查：给台面装定规

本节摘要：格式化器管排版，代码检查器管对错，两者是输出端的一对定规。本节打通"保存即格式化"管线，配置默认格式化器与按语言指定，讲清检查器的规则等级与自动修复协作，并处理"格式化器和检查器互相改代码"的经典冲突。装完这对定规，代码风格之争从评审会上彻底消失。

写完的代码像刚下刨床的木料，尺寸对不对另说，表面总归毛糙。手工打磨（对齐、调缩进、挪换行）费时且不稳定，同一双手在不同疲惫程度下磨出来的光洁度都不一样。工位的解法是装定规：格式化器统一排版，检查器盯住对错。上一节把输入端调顺了，这一节接管输出端，是第二轮开工前必须立好的规矩。

适用场景：什么时候上这对定规

判断信号很直接。团队评审里反复出现"这里缩进差一格""引号风格不统一"这类纯样式意见，评审时间被排版消耗——缺格式化器；提交后的代码能跑但隐患多（未用变量、可疑的相等比较、漏掉的边界分支），往往要到测试阶段才炸——缺检查器。两者一个管"长什么样"，一个管"会不会坏"，职责正交，缺哪个补哪个，不必捆绑采购。

安装与配置：先通管线，再分语种

管线的核心是把"保存"这个动作变成"格式化"的触发器，并给每类文件指定信得过的格式化器：

{
  "editor.formatOnSave": true,
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "[python]": {
    "editor.defaultFormatter": "ms-python.black-formatter"
  },
  "[markdown]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "editor.codeActionsOnSave": {
    "source.fixAll": "explicit"
  }
}
​

这段配置说清了三件事：保存即格式化全局打开；总体默认格式化器用通用排版器，Python 文件单独指到该语种的原厂格式化器（各语言整备详见第 4 章）；保存时同时执行检查器的"自动修复"动作，把能机器改的问题（未用导入、可自动修的规则违例）一并改掉。

格式化器本体认项目配置：通用排版器会读取项目根下的排版配置文件，团队把缩进宽度、引号风格、行宽写在那里，编辑器端只是执行者。这一点很关键——风格规则的唯一真相源在项目仓库，不在个人设置里，新人 clone 下来保存一下，风格自动对齐。

{
  "semi": true,
  "singleQuote": true,
  "printWidth": 100,
  "tabWidth": 2,
  "trailingComma": "none"
}
​

上面是通用排版器的项目配置示例：分号保留、单引号、百字符行宽。数字本身不重要，重要的是它们由仓库统一持有。

检查器这边的配置重心在"哪些规则开、开到多严"。以JavaScript生态最常用的检查器为例，规则分三档：报错、警告、关闭。建议的起步姿势是继承官方推荐集，再按团队痛点微调，而不是从零发明规则集：

{
  "extends": ["eslint:recommended"],
  "rules": {
    "no-unused-vars": "warn",
    "no-console": "warn",
    "eqeqeq": "error",
    "prefer-const": "error"
  }
}
​

图 2-2：保存一次代码后发生的事

台面实测：一次评审会的变化

拿一个真实场景看效果。某小团队的代码评审会，此前每轮都要花小半时间争论缩进与引号。装上这对定规并提交配置进仓库后：第一周，老代码在被改动的文件上"顺手"被保存动作统一了风格，仓库里的风格逐文件收敛；第二周起，评审意见里样式类意见归零，剩下的全是逻辑与设计讨论。检查器则在同期的提交里拦下了未使用变量与可疑相等比较，问题在写的时候就地暴露，而不是等到测试阶段回溯。

坑点提醒

坑一，定规打架。 最经典的冲突：格式化器要求句尾加分号，检查器的某条风格规则要求不加分号，保存一次、检查器自动修复改回去、再保存再改，光标看着代码左右横跳。解法是明确主权：风格类规则一律从检查器规则集里移除，全部交给格式化器；检查器只留正确性规则。坑二，多人多机不同结果。 有人保存后格式不对，多半是没装格式化器插件或项目配置文件没被拉到——把插件写进工作区推荐清单可根治。坑三，保存时卡顿。 大文件上保存即格式化叠加全套自动修复会有可感延迟，可改为只开格式化、修复动作改由手动触发，或按语种关闭重型修复。

替代方案

不喜欢"保存即改"的保守路线：把格式化挪到提交环节，由版本控制的钩子在提交前统一跑格式化器与检查器，编辑器端只做诊断显示——好处是绝对统一，代价是反馈回路变长。轻量路线是只用编辑器内置的格式化入口（快捷键手动触发），不配自动管线，适合个人玩具项目。团队正经仓库，我的建议始终是保存即格式化加提交钩子双保险。

常见疑问快答

问：保存时有时格式化有时不格式化，像抽奖一样，为什么？答：九成是“按语言指派”没配全——某类文件没有默认格式化器时，保存动作就静默跳过。检查设置里的语言块，把项目涉及的语言逐一指派；再查装备是否全员安装（没装格式化器的人，配置再对也不生效）。

问：格式化器能不能只格式化我改过的行？答：部分格式化器支持“增量模式”或通过区间格式化命令近似实现，但更通行的做法是全文件格式化加版本控制的行级差异审阅——改动行清晰可见，格式化噪音可辨。追求“只格式化改动行”往往是为了迁就老仓库，那种场景更适合按目录渐进式开启。

问：检查器报的警告要不要全部清零？答：分级对待。错误级必须清——它标记真实缺陷；警告级应该清——它标记强烈嫌疑；提示级可以忍——它多是风格与优化建议。把规则集调到“错误零容忍、警告高容忍”的档位，团队的心智负担最健康。

收束与下一站

输出端的定规立好了：排版交给格式化器、对错交给检查器、风格真相源进仓库。下一节从"写"转向"找"与"改"——导航与重构装备，把大文件里的路径钉在墙上。