Ruff v0.16.0：默认规则暴涨至413条
Ruff v0.16.0 – Significant new updates – 413 default rules up from 59
Ruff v0.16.0 正式发布，这次更新带来了巨大的变化：默认启用的规则数量从之前的 59 条激增至 413 条。这意味着无需任何额外配置，Ruff 就能自动捕捉包括语法错误和运行时错误在内的严重问题。新版本还稳定了多项功能，支持对 Markdown 文件中的 Python 代码块进行格式化，并引入了更灵活的 `ruff: ignore` 注释机制来抑制诊断信息。此外，`check` 和 `format --check` 命令现在会直接在输出中显示修复差异。作为用 Rust 编写的超快 Python 代码检查器，Ruff 继续巩固其替代 Black、Flake8 等工具的地位，帮助开发者更高效地编写代码。
Ruff 是一个用 Rust 编写的极其快速的 Python 代码检查器和格式化器。
HN 评论区
231- nickjj
前几天我用这个更新了一个大约 3000 行的 Python 项目。之前我使用的是 v0.15.x 版本。更新过程没花太多时间，新规则确实提升了代码质量。它发现了不少旧版本没抓到的问题。
以下是几处修改的提交记录：
（根据它的建议进行的一堆手动修改）https://github.com/nickjj/plutus/commit/9af66d31f98bef841588...
（重新启用行长度限制）https://github.com/nickjj/plutus/commit/21789f89bbcee37913c1...
（强制未使用变量加 _ 前缀）https://github.com/nickjj/plutus/commit/a272c77b932e1c78558a...
（由 Ruff 自动修正）https://github.com/nickjj/plutus/commit/6fe69cf88385ebdf9b8c...
- maratc
人们对这些“语法警察”式工具的痴迷程度真让我惊叹不已——其中一些工具执行的完全是任意的“规则”，还有一些工具对什么是“好”的 Python 代码甚至看法不一。
看这段“坏”代码：
important_numbers = {
'x': 3,
'y': 42, # Answer to the Ultimate Question!
'z': 2
}
再看“好”代码应该长什么样：
important_numbers = {"x": 3, "y": 42, "z": 2} # Answer to the Ultimate Question!
这完全曲解了作者的意图。但你注意到现在井号前面有两个空格了吗？还有，引号变成了双引号，因为据说这样更“正统”！真是巨大的进步啊！
我日常工作中遇到的真正问题，根本不是行尾空格或导入顺序未按字母排列，而是那些长达 10 行的列表推导式，长到我根本没法解析。这些工具一个都抓不到。我之前的项目用过 pylint、flake8、black、ruff，每次改动都要改几百次提交。这些精力本可以花在更有价值的地方。
- woadwarrior01
很高兴看到 Ruff、ty 和 uv 在被 OpenAI 收购 Astral 之后依然保持活跃开发。
- gempir
真希望 Go 语言也有像 Ruff 这样的工具！很多语言都拥有了出色的工具，但 Go 的生态非常碎片化，工具一大堆，却没有哪个能像 Ruff、Oxc、Biome 甚至 PHP 的 Mago 那样让人觉得高质量。
- jon-wood
我真希望 Ruff 能引入类似 Nix 的 stateVersion 机制，用来确定将应用哪一套默认规则。目前，在单个仓库之外的大规模更新 Ruff 有点像掷骰子，因为每个新版本都会引入一堆新的默认规则，你不得不立刻处理它们（要么关闭，要么修复）。
我知道我们可以设置一个白名单来指定所有启用的规则，但我更希望配置文件能更简单，并且能在大家方便的时候提升 stateVersion，花几个小时集中修复新的违规项。
- hyeongjun
好消息。默认启用 413 条规则意味着大多数项目无需触碰配置文件就能获得有用的代码检查！
- kstenerud
这是个好消息！随着代理式编程（agentic coding）的兴起，强大的代码检查比以往任何时候都更重要。我真正想看到的是针对更多语言的 forbidigo。
- luciana1u
413 条规则，结果我加入的每个代码库还在为同样的三个关于导入排序的争论不休。