code-formatting

#code-formatting

# 引导 Zig Fmt 在过去的几个月里，我一直在研究 Zig 格式化工具（`zig fmt`）的演变方向，最终形成了[这份提案](https://github.com/ziglang/zig/issues/20078)。由于这是一个颇具争议的话题，我想在这篇文章中详细阐述其中的权衡考量。 ## 现状 `zig fmt` 是一个固执己见的格式化工具：它会将 Zig 代码格式化为单一的规范形式，且不受用户配置的影响。这类工具（如 `gofmt`、`prettier`）有一个显著优势：当整个生态系统都使用同一格式化工具时，就能消除围绕风格的无谓争论，并确保所有代码的外观一致。然而，现有的 `zig fmt` 存在一个问题：它实际上并不是完全固执己见的——格式化结果会根据用户的输入而变化。以下面这个例子为例： ```zig const x = foo(1, 2, 3); ``` 如果你在最后一个参数后面加上一个逗号： ```zig const x = foo(1, 2, 3,); ``` `zig fmt` 会将其格式化为： ```zig const x = foo( 1, 2, 3, ); ``` 这意味着代码的格式化方式（单行还是多行）取决于用户是否添加了尾随逗号。此外，`zig fmt` 对于其他一些构造也并非完全固执己见，例如注释的位置。 ## 问题所在为什么这是个问题呢？毕竟，根据尾随逗号来决定格式化方式，这是一种广为人知且合理的约定。问题在于，这种方案实际上给了用户两种选择：单行格式和多行格式。这意味着用户必须做出决定，而这恰恰是格式化工具本应消除的那类决策。更糟糕的是，这个决定并没有一个客观正确的答案，因为适合单行还是多行，往往取决于行的长度——而行的长度会随着变量名、参数等的变化而改变。举个例子，假设你有： ```zig const x = foo(1, 2, 3); ``` 这段代码很短，放在一行完全没问题。但如果函数名变长了呢？ ```zig const x = a_longer_function_name(1, 2, 3); ``` 还是挺短的。那如果更长呢？ ```zig const x = a_much_much_longer_function_name(argument_one, argument_two, argument_three); ``` 这行已经相当长了，或许应该换成多行格式： ```zig const x = a_much_much_longer_function_name( argument_one, argument_two, argument_three, ); ``` 但在当前的 `zig fmt` 机制下，你需要手动添加尾随逗号来触发这个格式化。如果你重构代码，将函数名改短，或者把参数替换为更短的名称，那么多行格式可能就不再必要了——但 `zig fmt` 不会自动帮你切换回单行格式，因为它会把尾随逗号视为"保持多行"的明确指令。 ## 解决方案解决方案是让 `zig fmt` 基于行长度自动决定使用单行还是多行格式。具体来说：如果一个表达式能放在一行内（不超过某个长度限制，比如 100 个字符），就使用单行格式；否则，使用多行格式。这正是 `prettier` 的工作方式，也是大多数现代格式化工具所采用的方案。这意味着尾随逗号将不再具有语义上的格式化含义。你可以写： ```zig const x = foo(1, 2, 3,); ``` `zig fmt` 会根据行长度自动决定使用哪种格式，而不是盲目地遵循尾随逗号的指示。 ## 争议点这项改动之所以有争议，主要有以下几个原因： 1. 人们习惯了现有的行为很多 Zig 开发者已经习惯于用尾随逗号来控制格式化。改变这一行为会打破他们的工作流程。 2. 基于行长度的格式化可能产生令人惊讶的结果当你重命名一个变量，导致某行超过了长度限制，整个表达式的格式可能会突然从单行变成多行。这种"蝴蝶效应"可能让人感到困惑。 3. 需要确定合适的行长度限制 100 个字符？80 个字符？这本身也是一个需要决策的问题，尽管它只是一次性的决策，而不是每次写代码都要面对的决策。 ## 结论尽管存在争议，我认为基于行长度的自动格式化是正确的方向。它让 `zig fmt` 真正成为一个固执己见的格式化工具，消除了用户需要做出的格式化决策，并确保代码在重构后始终保持最优的格式。这与 Zig 语言的整体设计哲学是一致的：减少不必要的复杂性，让工具为开发者做出明智的决策，从而让开发者能够专注于真正重要的事情。

Lobsters Hottest ↗ · 12小时前缓存

# 两个让 `zig fmt` 更好用的技巧 Zig 配备了一个内置的代码格式化工具 `zig fmt`。与其他语言的格式化工具不同，`zig fmt` 是"可操控的"——某些语法结构会影响格式化的输出结果。本文将介绍两个实用技巧。 ## 技巧一：尾随逗号控制布局 `zig fmt` 会根据是否存在尾随逗号来决定参数的排列方式。 **没有尾随逗号**时，格式化工具会尝试将所有参数放在同一行： ```zig const result = myFunction(argument1, argument2, argument3); ``` **有尾随逗号**时，格式化工具会将每个参数单独放在一行： ```zig const result = myFunction( argument1, argument2, argument3, ); ``` 这个规则同样适用于函数定义的参数列表、结构体字段、枚举变体等场景。 ```zig // 单行：无尾随逗号 const Point = struct { x: f32, y: f32 }; // 多行：有尾随逗号 const Point = struct { x: f32, y: f32, }; ``` 这意味着你可以通过添加或删除尾随逗号来主动控制格式化的输出，而不必与格式化工具"博弈"。想要多行展示？加上尾随逗号。想要单行展示？去掉它。同样的逻辑也适用于换行符。如果你在参数之间手动添加了换行符，`zig fmt` 会尊重这个选择并保留多行格式——前提是同时带有尾随逗号。 ## 技巧二：数组的列式格式化对于数值数组，`zig fmt` 支持一种特殊的列式格式化方式，非常适合用来表示矩阵或表格数据。只需在数组元素之间手动插入换行符，`zig fmt` 就会将数据对齐成整洁的列式布局： ```zig // 格式化前（你写的） const matrix = [_]f32{ 1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 1.0, }; ``` ```zig // 格式化后（zig fmt 输出） const matrix = [_]f32{ 1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 1.0, }; ``` `zig fmt` 会识别出你在每行放置了相同数量的元素，并将各列对齐，使代码更具可读性。这对于表示变换矩阵、查找表或任何具有内在行列结构的数据来说极为方便。 ```zig // 一个更直观的例子：查找表 const sine_table = [_]f32{ 0.000, 0.174, 0.342, 0.500, 0.643, 0.766, 0.866, 0.940, 0.985, 1.000, 0.985, 0.940, 0.866, 0.766, 0.643, 0.500, }; ``` ## 小结 `zig fmt` 的"可操控"设计哲学让格式化工具成为你的合作伙伴，而不是独裁者： - **尾随逗号** → 强制多行展开 - **无尾随逗号** → 允许单行折叠 - **手动换行 + 统一列数** → 触发列式对齐掌握这两个技巧，你就能在享受自动格式化便利的同时，保留对代码视觉呈现的精确控制。

0 人收藏 0 人点赞

#code-formatting

一夜之间格式化2500万行代码库：rubyfmt的故事

Lobsters Hottest ↗ · 2天前缓存

Stripe工程师分享了他们使用rubyfmt在一夜之间格式化2500万行Ruby代码库的经验，重点介绍了开发者生产力的提升。

0 人收藏 0 人点赞

code-formatting

一夜之间格式化2500万行代码库：rubyfmt的故事

提交意见反馈