风格为什么交给工具
格式与风格应当由格式化器与 lint 自动处理：它们判断一致、执行成本低，而且不会因为评审者当天心情不同而变化。人的注意力应该花在设计与正确性上。团队约定「工具管风格，人管设计与正确性」之后，评审里关于括号位置、引号风格的争论会自然消失，评审信噪比明显提高。
基本信息
| 工具分工 | 格式化器管排版，lint 管可自动判定的规则问题 |
|---|---|
| 落地方式 | 提交钩子自动执行，CI 只做检查 |
| 人的范围 | 设计、正确性、可读性中需要理解意图的部分 |
| 配置变更 | 工具配置本身要评审：一改全库，影响面大 |
哪些交给工具
- 缩进、换行、引号、尾随逗号、行尾空白这类纯排版问题。
- 导入顺序与分组：交给 isort 或等价规则。
- 命名大小写、未使用变量、可疑写法：交给 lint 规则集合。
- 文件末尾换行、制表符与空格混用：交给格式化或编辑器配置。
哪些仍需要人
- 可读性：变量名是否表达意图，函数是否承担多件事。
- 结构：抽象层次是否混乱，模块边界是否合理。
- 取舍：为可读性放弃的写法是否值得，是否有更直白的替代。
- 一致性：与代码库既有约定是否冲突，特别是工具管不到的部分。
- 接口与数据结构的取舍：工具只保证格式一致，不保证设计合理。
策略对比
| 策略 | 结果 |
|---|---|
| 工具管格式、人管设计 | 评审聚焦重点，速度快 |
| 人工检查格式 | 注意力被消耗，标准随人波动 |
| 工具配置常改 | 全库重排反复出现，冲突集中爆发 |
| 只有约定没有工具 | 约定形同虚设，几乎无法长期维持 |
把风格从评审里移除，是提升评审信噪比成本最低的一招。
评审仍可提可读性问题，但要指向理解成本：用「读起来要跳回去看定义」替代「我不喜欢这种写法」。
工具版本升级同样要走评审：格式化行为一旦变化，全库 diff 会集中震荡。