# 引导 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 语言的整体设计哲学是一致的：减少不必要的复杂性，让工具为开发者做出明智的决策，从而让开发者能够专注于真正重要的事情。