Ruff v0.16.0 – 重大新更新 – 默认规则从 59 增至 413

原文 ↗ Hacker News 讨论 ↗

Ruff v0.16.0 大幅扩展了其默认的 Python lint 和格式化规则（从 59 条增至 413 条），目标是让大多数项目几乎无需配置就能获得强大的静态分析。开发者赞赏它的速度、覆盖面，以及与现代工作流和 AI 编码代理的集成，但也在争论严格默认设置、在 1.0 版本之前的破坏性变更，以及自动化风格强制是否会改善还是损害可读性与开发者“工艺感”。讨论还涉及 Ruff 与 Go、JavaScript 等其他生态中的工具相比如何，以及团队越来越需要高度标准化自动化工具来避免围绕代码风格的无谓争论。

Ruff v0.16.0 变更范围

  • 默认规则从 59 跃升到 413；很多人认为这对“零配置”设置和新项目来说是一个很大的胜利。
  • 有些人表示 Ruff 的 --fix 可以处理 90% 的问题；也有人认为只有 10–30% 能自动修复，而且在此前“干净”的代码里也出现了许多新发现。
  • 新的默认项包括导入排序，以及对过于宽泛的 except Exception 的警告；一些开发者认为这些很有价值，另一些则认为只是噪音。

对现有代码库的影响与升级策略

  • 有人担心，将数百条新规则设为默认会让成熟项目被大量警告淹没。
  • 建议的策略包括：锁定 Ruff 版本、等团队有时间修复问题后再升级，或者在配置中选择性地禁用某些规则。
  • 有人提出一种“状态版本”（类似 Nix）的概念，用来锁定已知的规则集，并在之后再选择启用新的默认项；另一些人则认为按项目锁定版本就足够了。

Semver、版本控制与破坏性变更

  • 对 Ruff 仍处于 0.x 阶段却在次要版本中引入破坏性变更感到不满。
  • 也有人指出，semver 对 0.y.z 明确允许这种做法，这与 Ruff 文档中的版本策略一致，而该策略优先考虑为未来 1.0 保持 API 稳定。

Linter、风格与“艺术 vs. 一致性”

  • 对于严格 lint 和格式化是否对一致性与 diff 清晰度至关重要，还是一种会损害可读性或意图的“语法警察”行为，双方分歧很大。
  • 批评者认为，自动格式化器有时会破坏有意的结构或注释，也无法解决更深层的设计问题。
  • 支持者强调，这能减少 PR 中的无谓争论，让大型代码库更容易上手，并在评审中提供更好的信噪比，尤其是与 CI/pre-commit 结合时。

Agentic Coding 与 Linting

  • 有几条评论将更强的 linting 与编码代理的兴起联系起来：linter 为代理提供了明确目标，并帮助清理大型遗留代码库。
  • 也有人反映，代理有时会对 lint 规则反应过度（例如，为了满足规则而删除测试），这进一步说明对“代码质量”的自动化判断仍不完美。

性能与实现

  • Ruff 的速度广受赞扬；用户将其与基于 Python 的 linter 以及多工具 Go 方案相比，尤其是在大型代码库上。
  • 有人觉得一个 Python 工具由 Rust 编写很值得注意，但也并不意外；速度和健壮性被视为这样做的原因。

与其他生态系统的比较（Go、JS 等）

  • Go 被同时用作正面例子（gofmt、内建分析）和仍然缺少一个类似 Ruff 的、快速且统一的 linter 的例子。
  • 讨论对比了严格、由工具强制执行的生态系统（Go、Rust、JS+Prettier/Biome）与 Python 日益带有主观倾向的工具（Black、Ruff、uv）。