我为什么换到了 Tab 缩进

曾经，我是 Space 的忠实粉丝，写 JavaScript 时，我用 2-space 缩进；写 Python/Rust 时，我用 4-space 缩进；写 Go 时，我用…… 好吧，它只能用 Tab。

直到去年，看到 Jake Archibald 推文，我又开始重新思考缩进的本质，并从 Space 过渡到了 Tab：

• Tab 本身就是专门缩进的字符
• Tab 宽度可调：可以设置 1-tab 显示为 1-space、2-space、4-space…… 而 Space 则是一种“硬编码”，永久固定死了缩进宽度，无扩展性可言
• Tab 更人性化：每个开发者都可以根据自身喜好，甚至是显示屏宽度，自由调整缩进尺寸。而不必强迫每个人都用 N-space 读你的代码
• Tab 永远只占 1 个 byte，更省空间
• Tab 无须纠结宽度：2-space 瞧不上 4-space，4-space 觉得 2-space 不正统。Tab 没这问题，很少有人问 Tab 宽多少，因为 Tab 就是 Tab，可调

无障碍

说实话，上面这些理由足够支撑我换到 Tab，但在看到 Change useTabs to true by default 这个 issue，让我换过去的想法更坚定了。

该 issue 引用的 Nobody talks about the real reason to use Tabs over Spaces 这篇 reddit 讨论，深深触动了我，让我意识到一个从未被人们认真讨论的话题 —— Accessibility。

无障碍是所有人面临的问题，而不是少数人，人们随时间变老，视力、听力、反应能力随之下降。在我老时，我也许需要放大字体，也许需要放慢速度，也许需要更大的点击区域，也许需要更大的缩进宽度。如果系统为 a11y 做了优化，这会让我感到很温馨。

以前，在我复制 UI 代码片段时，会删掉 aria-label、aria-hidden 这些属性，因为没人 care 这个，留着反而让代码显得更乱。现在，我会默默地保留它们，并看到越来越多的人开始重视 a11y，而为之感到振奋。

常见问题

Q：Tab 的支持程度？
A：所有主流编辑器都支持调整 Tab 宽度，配合 EditorConfig 甚至能为不同文档类型、不同路径设置不同的 Tab 宽度，比 Space 灵活不少。而这些都是可以随时调整的，因为不是“硬编码”。

Q：GitHub 能调 Tab 宽度吗？
A：可以，GitHub 支持多种调节 Tab 的方式，最简单的是设置 Settings - Appearance - Tab size preference。我目前设置为 2，所有 Tab 为我呈现 2-space 宽度。另外 GitHub 也会尊重 repo 中的 .editorconfig 正确渲染 Tab。

Q：Tab 和 Space 能混用吗？
A：可以，一般叫 “Soft Tabs” 或 “Smart Tabs”，不建议，因为可能会：

Q：你没说服我！我还是想继续用 Space。
A：当然可以！如果你能忍受每次敲击 “Tab” 键，实际蹦出来几个 “Space” 这种被 NTR 了的感觉（逃）

目前配置

• 新项目使用 Tab 缩进，所有语言 tab size 设置为 2
• 使用双引号。以前我喜欢单引号，但会和字符里的英文冲突，"world's fastest car" vs 'world\'s fastest car'，前者没这问题。写到一半转义、换双引号，不如始终双引号
• 能不加分号的语言，不加分号